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

Greg KH greg at kroah.com
Wed May 11 08:37:19 PDT 2011


On Wed, May 11, 2011 at 11:30:52AM -0400, Stephen Smalley wrote:
> On Wed, 2011-05-11 at 08:13 -0700, Greg KH wrote:
> > On Wed, May 11, 2011 at 10:54:38AM -0400, Stephen Smalley wrote:
> > > On Wed, 2011-05-11 at 16:27 +0200, Kay Sievers wrote:
> > > > Just to get an idea how all this fits together. How can TPM bios and
> > > > IMA/AppArmor share this directory? They have their own subdirs in
> > > > there, or both just use the securityfs infrastructure and not their
> > > > own filesystem on top?
> > > 
> > > They create their own subdirs under /sys/kernel/security.
> > > tpm0, ima, apparmor, etc.
> > > They create nodes in securityfs rather than implementing their own
> > > pseudo filesystem type.
> > 
> > Then I have to ask, why is selinuxfs different here?  Does securityfs
> > not provide you the api you needed to implement selinuxfs on top of it
> > without haveing to be a separate filesystem?
> 
> selinuxfs was merged into mainline in 2003 and included in Linux 2.6.0.
> securityfs was merged in 2005, well after selinuxfs was already shipping
> in distros and userspace was relying on existence of selinuxfs
> in /proc/filesystems as an indicator of whether or not SELinux is
> enabled.  So we're different in part due to history and in part for the
> sake of preserving userspace compatibility.

Ok, fair enough.

> Even aside from that, I think there are various aspects of selinuxfs
> functionality that would need new interfaces from securityfs to support,
> although I can't say that I've looked deeply into it.  Assigning
> specific inode numbers to specific inodes so that we can mask out an
> index for use within the operations, supporting transaction based I/O
> methods, fine-grained labeling of certain inodes (e.g. booleans), mmap
> support for /selinux/policy and /selinux/status, etc.

Yeah, doesn't seem worth it, thanks for the information.

greg k-h


More information about the systemd-devel mailing list