On 5/11/2011 1:40 PM, Eric Paris wrote: > On Wed, May 11, 2011 at 4:22 PM, Greg KH <g...@kroah.com> wrote: >> On Wed, May 11, 2011 at 04:14:32PM -0400, Eric Paris wrote: >>> On Wed, May 11, 2011 at 3:56 PM, Greg KH <g...@kroah.com> wrote: >>>> On Wed, May 11, 2011 at 10:14:40AM -0700, Casey Schaufler wrote: >>>>> I would prefer /sys/security for all LSMs, but if SELinux goes with >>>>> /sys/fs >>>>> Smack will likely follow on the theory that mirroring the current dominant >>>>> LSM is more likely to please the masses than doing what the greatest >>>>> number >>>>> of LSMs are doing. >>>> Is smack going to create its own filesystem like selinux has, or is it >>>> going to use securityfs? If securityfs, then stick with what you have. >>>> If you are going to create a new one, I'd be glad to work with you to >>>> add anything you might need to securityfs first, but if that doesn't >>>> work out, then yes, you could use /sys/fs/ for your new one. >>> Pretty sure we already have a securty/smack/smackfs.c ..... >> Doh, you are right. Ok, I'll just shutup now then... >> >> greg k-h > I'm willing to put in a day or two trying to move selinux to > securityfs, but there is one thing I'm not sure how to handle, mainly > when it comes to userspace backwards compat. Greg, maybe you can give > me ideas. > > My biggest issue is how libselinux historically found selinuxfs. > Given that people will likely use this library forever even with new > kernels (*cough* akpm *cough*) I sorta feel like we need to continue > to support it. The libselinux library had 3 tests. > > 1) check statfs(2) on /selinux and if it was selinuxfs magic we are done > 2) check /proc/filesystems to see if selinuxfs exists, if not, selinux > is disabled > 3) check /proc/mounts and find if/where selinuxfs is mounted > > If we just move the selinuxfs mount around the filesystem it's no big > deal. The old library will find it. It would be new userspace that > mounted it in a new place, so that new userspace could make the check > in (1) look at the new place. If we actually replace selinuxfs with > securityfs step 2 is going to fail. I can probably fake it somehow > and pretend that selinuxfs exists as an fs, but I don't really know > how to fake /proc/mounts so even though /sys/kernel/security/* is > actually securityfs /sys/kernel/security/selinux looks like selinuxfs > in /proc/mounts. > > I guess maybe the way to do it is to make selinuxfs as it stands today > a config option. I don't see a reason we couldn't implement a whole > new set of selinux inodes in securityfs along with those in selinuxfs. > Old userspace would mount selinuxfs on /selinux and would need the > compat kernel option while new userspace would change it's tests to > be: > > 1) check for /sys/kernel/security/selinux/"something" > 2) check for securityfs and if not assume disabled > 3) check /proc/mounts and find securityfs, then check for "something" > > I'd rather not have two complete implementations of selinuxfs but if > it gets us to a good endgame I guess I'm willing to support it.... >
Isn't it about time we had /sys/kernel/lsm, which would contain the name of the active LSM? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
