Stephen Smalley wrote:
On Thu, 2006-04-13 at 18:35 +0100, Ron Yorston wrote:
Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
Seems like a policy bug (omission of a transition from unconfined_t to
mount_t) to me. Otherwise, /etc/mtab is going to lose its type every
time you run mount/umount from the shell. Dan?
Just a clarification (or confusion): it's only umount that causes the
problem. mount doesn't create a new /etc/mtab file and doesn't change
the context:
# ls -Z /etc/mtab
-rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab
# ls -i /etc/mtab
33032 /etc/mtab
# mount /opt
# ls -Z /etc/mtab
-rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab
# ls -i /etc/mtab
33032 /etc/mtab
#
Ah, ok. strace of mount and umount suggests that mount just
writes/appends to the existing file in place while umount creates a new
file without the entry and then replaces the original file via rename.
Which would explain why mount doesn't disturb the type but umount does.
Regardless, I think it makes sense to have unconfined_t transition to
mount_t.
Please turn on restorecond
chkconfig --add restorecond
service restorecond start
We are not transitioning to mount_t from unconfined_t because it causes
lots of other problems such as
mount > ~/mymounts failing etc. This is the type of problems
restorecond is designed to fix.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
