Bob Gustafson wrote:
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).
Log files are stored in /var/tmp to avoid the conflict. They should
survive the reboot.
----
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.
We moved around the pam_xauth and pam_selinux open calls in
/etc/pam.d/su (coreutils)
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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
