Loadable security modules for D-Bus

Marcel Holtmann marcel at holtmann.org
Wed Jan 11 02:31:29 PST 2012


Hi Simon,

> >> Splitting the packaging of D-Bus into a base
> >> package and a package for each security module to break up dependencies is
> >> more appealing than, creating separate D-Bus packages to support different
> >> security solutions.
> >
> > Yeah, I think the clear answer here is: this must be upstream. The API
> > of D-Bus is huge and baroque as it is, increasing the standardized API
> > surface even further by adding a plug-in interface would be crazy.
> 
> I agree. A purely-internal dlopen interface (in which the dlopen'd 
> modules are D-Bus-version-specific, so support for SELinux, AppArmor and 
> whatever else must all be built from the dbus source tarball) seems 
> reasonable, but a stable API which allows out-of-tree modules would be a 
> bad move. I suggest having the module directory name, or even the module 
> filename, include the D-Bus version (e.g. 
> ${libdir}/dbus-1.5.67/libdbus-daemon-selinux.so) to make it explicit 
> that no, this is not a stable API.
> 
> Thankfully, this seems to only be needed for Linux LSMs, so we can 
> simplify to "only build it on Linux, where we know dlopen() works 
> sensibly" rather than having to do the same portability contortions as 
> libltdl and GModule.

using dlopen just for the sake of it being available is crazy as well. A
good build system can just build the code and does not have to do
dlopen. Especially if it is known upfront what will be available and
what not.

Regards

Marcel




More information about the dbus mailing list