Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > Quoting James Morris ([EMAIL PROTECTED]): > > > Convert LSM into a static interface, as the ability to unload a security > > > module is not required by in-tree users and potentially complicates the > > > overall security architecture. > > > > > > Needlessly exported LSM symbols have been unexported, to help reduce API > > > abuse. > > > > > > Module parameters for the capability and root_plug modules have been > > > converted to kernel parameters. > > > > > > The SECURITY_FRAMEWORK_VERSION macro has also been removed. > > > > Sigh, as much as I would *like* to stay out of this (I don't > > use modules at all on any system where I can avoid it), won't > > it make development - and especially testing - of new lsms > > much more painful and therefore less likely? > > While there's lots of pain involved in developing an LSM > modern development environments (e.g. virtual machines) > have reduced the value of loadable modules for debug purposes. > > > I realize there has been a dearth of new LSMs to date, > > but so much excitment over those proposed! > > > but if > > for instance a new solaris 10 based capability module were written, > > well, people would want to be able to > > > > rmmod capability > > modprobe cap_prm > > I think the value is overrated. You would never want to do that > in a production environment, and in a debug environment you could > just as easily reboot and get some start-up testing out of the way.
And in a development environment you can just as easily select CONFIG_XYZ=y, no? So we have two options, one which provides greater choice and flexibility. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
