How to properly upgrade policy

Daniel J Walsh dwalsh at redhat.com
Fri Jun 25 10:17:34 UTC 2004


Ivan Gyurdiev wrote:

>On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
>  
>
>>On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
>>    
>>
>>>What's the proper way to upgrade the selinux policy?
>>>
>>>yum and rpm leave me with .rpmnew files every single time.
>>>      
>>>
>>This suggests that you installed the policy source package as well, or
>>locally modified your policy directly.  If you install or update the
>>policy source package (selinux-policy-strict-sources), then it should
>>rebuild the policy files from source and load the new ones automatically
>>as part of the %post.  Updating the policy package
>>(selinux-policy-strict) will then leave you with .rpmnew files because
>>it sees that the files have been locally rebuilt.
>>    
>>
>
>Yes, I have the sources package instaled - I need it to make relabel
>don't I? Since I upgrade through yum, and rawhide updates the sources
>package with the other one, I always update them together. However, the
>resulting files are not the same - file_contexts and file_contexts.
>rpmnew are different, and the binary policy differs too.
>
>
>  
>
>>>Do I need to run make relabel?
>>>
>>>______________________________________________________________________
>>>      
>>>
>>It is generally safest to do so, but often unnecessary (only if there is
>>a relevant change to file_contexts that affects you).  Relabeling is not
>>presently automatically performed upon a policy update.
>>    
>>
>
>Are there plans to change that?
>
>
>  
>
No because this could be a very long process.   We are hoping to not 
change policy very often and less often change File Contexts.  
Especially with Targeted policy.  I have modified fixfiles to be able to 
use RPM files as input and we are looking into a cron script to walk the 
file system on a regular basis to inform users of problems in the file 
context.  This script could either repair the problems automatically 
(Not recommended), or easily allow the administrator to fix them the 
next morning.  

Setfiles and restorecon have a new qualifier (-o filename) which will 
record the file paths of any files that the tools find with the 
incorrect security context.  So if you run setfiles -n -v -o 
/tmp/badfilecontexts, you would have a report and a file with all the 
paths of files with bad file contexts.  If everything looks ok, you 
could run restorecon -f /tmp/badfilecontexts and clean them up quickly.

Dan

>------------------------------------------------------------------------
>
>--
>fedora-selinux-list mailing list
>fedora-selinux-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>




More information about the fedora-selinux-list mailing list