[systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs

[Greg KH]

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