Off-topic: D-Bus in the kernel

[Alban Crequy]

Le Mon, 20 Sep 2010 10:30:26 +0100,
Richard Hughes <hughsient at gmail.com> a écrit :

> On 17 September 2010 18:52, Ray Strode <halfline at gmail.com> wrote:
> > In theory if this was handled on the kernel side it could set the
> > login uid properly on the activated process instead of using the
> > login uid of the bus daemon.
> 
> I'm not sure this makes sense, as packagekitd can be auto-started by
> user 'bob' and then used to install a package, and then user 'sally'
> can use the same daemon instance to remove a package. The daemon only
> quits after 10 seconds of idleness.
> 
> Requiring system-activated daemon to quit after ever user action would
> demolish performance IMHO.

In the same way the ability to send file descriptor in D-Bus message
with SCM_RIGHTS ancillary data was added in D-Bus 1.3.0, the
D-Bus protocol could be enhanced to send SCM_CREDENTIALS ancillary data
(see man unix(7)) with pid, uid and gid. The value pid+uid+gid sent by
a process are checked by the kernel, so the process cannot write random
values.

With the current dbus-daemon, it would not work because when
dbus-daemon relays the D-Bus message, the kernel would check the
pid+uid+gid values against the process dbus-daemon and dbus-daemon is
not running as root, so the kernel will not let it fake the IDs.

But if a D-Bus message is delivered directly (with a peer to peer
D-Bus connection or with kdbus bypassing dbus-daemon), the pid+uid+gid
will be correct and checked by the kernel.

In your example, packagekitd can run as a privileged user with D-Bus
activation, auto-started by either 'bob' or 'sally' but when they send
D-Bus method calls to install and remove packages, packagekitd would
know which user initiated each request and could log that. It would not
be the login uid, but maybe it is enough for auditd?

The daemon would not need to be restarted after every user action.

Alban