Stephen Smalley wrote:
On Fri, 2005-03-25 at 12:56 -0500, Bill Nottingham wrote:it still does not work with the restorecon /tmp line and the policy changes....
Stephen Smalley (sds@xxxxxxxxxxxxx) said:
A question: why don't mounts normally inherit the context of thein 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;
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.
same avcs...
