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
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
