Stephen Smalley wrote:
On Thu, 2006-04-13 at 18:35 +0100, Ron Yorston wrote:
> Stephen Smalley <sds(a)tycho.nsa.gov> 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.