selinux fixfiles context

Daniel J Walsh dwalsh at redhat.com
Thu Apr 15 12:15:27 UTC 2004


Thomas Molina wrote:

>Does it matter in which context corrective actions for selinux problems 
>are performed?  Since starting to experiment with test2 I have seen a number of issues and 
>opened several bugs.  Beyond actual "bugs", resolved by package updates, 
>most issues seem related to selinux context and file labels/attributes.  
>
>The most offered advice is to do a "fixfiles relabel".  For the issues I 
>am looking at on my system this has been largely unsuccessful until last 
>night, and I am wondering if there is a connection.  I have been running 
>selinux in permissive mode, and Fedora Core has been in runlevel five.  I 
>would log in as a regular user, open gnome-terminal, and do a "su -".  id 
>-Z would confirm I am running in sysadm role.  relabeling has not resolved 
>my issues.
>
>Last night I decided to try something different.  I dropped down into 
>single user mode before relabeling.  Since then, the avc denied messages 
>have largely disappeared.  
>
>Does system state matter, is single user mode irrelevant, or is there some 
>other issue here?
>  
>

Yes I always relabel in single user mode.  A process that is already 
running will not be
directly affected by a relabel.  The file context is only looked at at 
process start.  So if
gnome is running in the wrong context and relabel.  gnome will continue 
to write in the
wrong context, until restart.   Most of your problems are probably files 
being created in the /tmp
directory.  As far as the advice of run fixfiles, that is happening way too
often.  When we have this working correctly fixfiles should never need 
to be run (Think of
it as fsck.)  Running in permissive mode is not the same as running in 
enforcing mode.  I would
suggest that you run in enforcing mode all the time.  If you run into a 
problem where something
will not work in enforcing mode, use setenforce 0 run your command and 
run setenforce 1.  Then
grab the AVC messages and submit a bug report.


>
>  
>





More information about the fedora-test-list mailing list