Re: How to properly upgrade policy

Daniel J Walsh <dwalsh@xxxxxxxxxx> · Fri, 25 Jun 2004 06:17:34 -0400

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@xxxxxxxxxx

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