Darren Reed wrote: <snip> > If we're going to support MAC plugins in the kernel then we need > to have a plugin interface to manage them from user space too, > a place where you can dump a shared library and have that "just > work" with the dladm command.
Yep, I agree with this, and I thought that this may be needed when implementing the MAC-Type plugin architecture. If we want to make that architecture public (the kernel architecture), then having a similar user-space architecture would be desirable, otherwise the administration of these MAC-Types is relegated to bags on the side. The architecture, however, doesn't belong in the dladm command, but rather in libdladm since that's where all of the class and type-specific stuff actually happens. Most of dladm would then need to be shoved into libdladm to make the architecture sane. > > The "flat verb namespace" that is present in dladm just doesn't > lend itself to the type of architecture that is required to support > the kernel MAC plugins - well, not in an obvious manner, anyway. > > Perhaps the parser could just as easily break "create-pigeon" > into "pigeon" and then ask the pigeon shared library to do > something with "create"... although I'm not sure it is good to > make people wait while dladm waits for an egg hatch ;-) It may not lend itself perfectly to such an architecture, but I think it's doable. We also don't know what verbs are applicable to future MAC-Types. Maybe create/modify/delete aren't applicable to them, and/or others that we haven't thought of are applicable. As such, maybe the current syntax is good enough to provide the right amount of flexibility for such a plugin architecture. -Seb _______________________________________________ networking-discuss mailing list [email protected]
