Loadable security modules for D-Bus

[Marcel Holtmann]

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