Loadable security modules for D-Bus

[Simon McVittie]

On 11/01/12 00:16, Lennart Poettering wrote:
> On Tue, 10.01.12 10:16, John Johansen (john.johansen at canonical.com) wrote:
>> 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.

     S