On Fri, 25 Jun 2004 06:17:34 -0400, Dan Walsh wrote: >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 > Sounds pretty good in the long term. However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r). It would be nice to get some sort of indication that a fixfiles run would be helpful when these gross changes occur. ---- There was a note awhile ago saying that the log from fixfiles would remain in the /tmp area, even though 'Y' was chosen to zap the /tmp files prior to relabel. Does this file survive the necessary following reboot? (I did not see it when I looked just now). ---- There was some talk of changing PAM so that it would better handle the 'su' operation. Has this been done? I ask this because I cannot get into any of my root priviledged Gnome applications anymore. This had been a problem, then it was fixed, now it is a problem (for me) again. It seemed as though the proposed PAM change would also enable a shutdown direct from Gnome - even though Gnome had originally been started up as a user application (it would of course ask for a root password). ----- I am currently (as of an hour ago) current on 'yum update' and I did a complete 'fixfiles relabel' at init 1 state before my last boot. BobG
