On Wed, 6 Jul 2005, Stephen Smalley wrote: > > Stephen: opinions on this? > > The reason for creating a kernel mount of selinuxfs at that point is so > that the selinuxfs_mount vfsmount and selinux_null dentry are available > for flush_unauthorized_files to use.
When exactly is this needed? The securityfs mountpoint will be available via a core_initcall, after which we can initialize the selinux subtree. > Userspace compatibility is obviously a concern for such a change. > libselinux determines where selinuxfs is mounted during library > initialization by checking /proc/mounts for selinuxfs, and rc.sysinit > does likewise. > > /sbin/init performs the initial mount of selinuxfs prior > to initial policy load. With securityfs, we'd have /sys/kernel/security/selinux configured during kernel initialization. > Further, the existence of selinuxfs > in /proc/filesystems is used as a test of whether SELinux was enabled in > the kernel (e.g. is_selinux_enabled in libselinux). Could be a simple change to look for the presence of /sys/kernel/security/selinux > I'm not sure such a change is worthwhile for SELinux; large amount of > disruption for little real gain. I think it should reduce and simplify the SELinux kernel code, with less filesystems in the kernel, consolidating several potential projects into the same security filesystem. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
