Off-topic: D-Bus in the kernel

Marcel Holtmann marcel at holtmann.org
Fri Sep 17 01:31:04 PDT 2010


Hi Remi,

> > not sure how you come to your conclusion. D-Bus is a well defined
> > inter-process/networking protocol and so it does make sense to implement
> > it in kernel space.
> 
> Sure.
> 
> > For the signal subscription via AddMatch, there
> > might is some extra work needed, but surely that is not argument to not
> > try it.
> 
> You don't (selectively) parse HTTP headers in the TCP/IP stack, do you?.
> AddMatch, and in fact, any (in-band) request to the bus will require
> parsing whole DBus messages in kernel space - or offloading to a user-space
> bus helper that instructs the kernel via some funky ioctl()s or similar.

we could use the socket filter actually for this. We have used that
nicely with udev and might work out here as well. Or some modified
version that does the matching. In the end D-Bus is a well-defined
binary protocol with a bunch of strings.

> >> But I expect the worst part of a kernel D-Bus to be the security
> >> enforcement. Parsing files in kernel space is a complete non-starter,
> >> and that includes service files. So it might be possible to move the
> >> session bus to kernel space, but I am not very optimistic about the
> >> system bus. Hmm, anyone fordbustables and NetFilter-DBus?
> > 
> > I don't see this as a problem. Of course nobody is parsing XML files
> > inside the kernel, but then again, the whole security of D-Bus should be
> > deprecated anyway.
> 
> That might be a good idea. But will this fly with the community at large?
> Kernel DBus might be a tough sell if it removes well-established
> "features".

I don't really call this a well-established feature. The security policy
file has been a problem for quite some time. It is not flexible enough.
And if you look at the installed policy files for your desktop Linux
system right now. You don't see much use of it anyway. Just the bus name
owner section is important. The rest is kind either allowed by default
or rejected by default. And the at_console part has been proven to be
pretty hard in reality. Hence a bunch of applications just rely on
PolicyKit instead D-Bus security policy.

Regards

Marcel




More information about the dbus mailing list