On 06/06/17 17:36, Tetsuo Handa wrote: > Igor Stoppa wrote: >> For the case at hand, would it work if there was a non-API call that you >> could use until the API is properly expanded? > > Kernel command line switching (i.e. this patch) is fine for my use cases. > > SELinux folks might want > > -static int security_debug; > +static int security_debug = IS_ENABLED(CONFIG_SECURITY_SELINUX_DISABLE); ok, thanks, I will add this > so that those who are using SELINUX=disabled in /etc/selinux/config won't > get oops upon boot by default. If "unlock the pool" were available, > SELINUX=enforcing users would be happy. Maybe two modes for rw/ro transition helps. > > oneway rw -> ro transition mode: can't be made rw again by calling "unlock the pool" API > twoway rw <-> ro transition mode: can be made rw again by calling "unlock the pool" API This was in the first cut of the API, but I was told that it would require further rework, to make it ok for upstream, so we agreed to do first the lockdown/destroy only part and the the rewrite. Is there really a valid use case for unloading SE Linux? Or any other security module. -- igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
