On Fri, 2005-03-25 at 12:56 -0500, Bill Nottingham wrote: > Stephen Smalley (sds@xxxxxxxxxxxxx) said: > > > in which file should I add this? > > > > After further discussion on selinux list, it looks like Dan is going to > > take a different approach and not use a fscontext= or context= mount. > > Instead, he is just adding a 'restorecon /tmp' line > > to /etc/rc.d/rc.sysinit so that it will get relabeled to tmp_t at that > > time, and Dan recently added the following to the policy: > > allow tmpfile tmpfs_t:filesystem associate; > > A question: why don't mounts normally inherit the context of the > directory where they're mounted in cases like these? You would need rather specialized handling of tmpfs in the kernel for that, since: 1) for conventional filesystems, you get the context from the on-disk xattr, not from the mount point, 2) for pseudo filesystems like /proc that don't create a separate instance per mount, you could have multiple mounts at different points, but you can only have one security context assigned. tmpfs is unusual since it creates an instance per mount. Neither the LSM hook nor the kernel function which calls it that performs setup of the superblock and root inode doesn't even have the mount point available to them; you'd have to use a hook in graft_tree or attach_mnt. -- Stephen Smalley <sds@xxxxxxxxxxxxx> National Security Agency
