Loadable security modules for D-Bus

[Lennart Poettering]

On Mon, 09.01.12 16:47, John Johansen (john.johansen at canonical.com) wrote:

> > I am strongly against doing this kind of dynamic module loading in the
> > D-Bus daemon. Quite frankly, this is just crazy. I see no reason at all
> > to have dynamically loaded modules here, if this can be statically
> > compiled in, then I see no reason at all to create a complex module
> > loading infrastructure with hooks and stuff.
> > 
> > If you want to introduce plug-ins somewhere then you need very strong
> > reasons why you want to do that, and why static compilation wouldn't
> > suffice. Usually that also means agreeing to some kind of sane API that
> > plug-ins can interface with, which means major API stability concerns. I
> > completely don't see how the disadvantages would be outweighed by any
> > advantage of introducing plug-ins for security modules here. In fact I
> > fail to see any advantage of having a plug-in interface in the bus
> > daemon.
> > 
> I don't see a need for this to be done as dynamically loadable modules,
> but I do see a need for supporting multiple security modules. Having them
> share common hook points where possible makes sense.

Well, for that a call like check_security() or something with that being
implemented in a new security.c or so should suffice. check_security()
would then be a series of #ifdef for the various systems... 

I think it would make sense not to sprinkle the entire code base with
code for the various security subsystems, but I think it is fine to have
a single file that contains all the security calls wrapped in #ifdef.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.