On Wed, May 11, 2011 at 04:40:33PM -0400, Eric Paris wrote: > 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.
You can't fake that out, you really need to mount a filesystem for /proc/mounts to show it. > 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.... The end result would be only one version of selinuxfs, right? Keeping two versions wouldn't be wise. I can't think of an easy solution here, sorry. greg k-h _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
