Red Hat Bugzilla – Bug 163668
RFE for local adaptation
Last modified: 2007-11-30 17:11:10 EST
This is really an RFE. There is probably a way to do it already that I do not
understand. I would welcome a pointer to documentation on how to effectively
administer selinux if you know of any. The supplied docs are, ahem, opaque.
Context: I run a server with several logical web severs. Each has its own file
tree. Also, I have two directories that need to be treated like /home: /home and
Problem: restorecon -R / screws up the file contexts on these non-conventional
Exacerbation 1: if I edit the file_contexts file, then updates of the selinux
Exacerbation 2: when that helpful dwalsh guy decides to update the contexts on
the "standard" locations, they don't propagate to my directories.
What I *think* I want is in three parts:
1. a way to say: "treat this directory /mumble and its sub-content in all
respects as though it were that other directory /home". I'm not stuck on "define
by example," but I at least want a way to know when my adapted config has gone
2. a way to add file contexts without editing the master file_contexts file.
Perhaps this might be done in a way similar to the handling of /etc/yum.repos.d/
or /etc/httpd/conf.d/, wherein all files present get loaded in unspecified order.
3. On the "your adapted config has gone stale", I *really* want to know this
*before* I reboot. On some occasions, selinux upgrade failures (primarily due to
the .rpmnew problem that I filed separately) have left me with machines that
don't reboot past single user mode. This leaves me doing an hour drive in and
out of work in the middle of the night to "recover" the file system with
restorecon and then patch it for my unusual directories. This prompts me to
suggest that I want more direct control on policy upgrades in the same kind of
way that I have on kernel upgrades -- for that matter, I wouldn't mind more
control over the kernel upgrades. It's bad enough that I'm about ready to put
selinux on my "do not upgrade automatically" list.
Not quite sure how to get the control. One possibility is to leave the existing
policy in place so that I can roll back. Another might be to leave the decision
to migrate forward as a manual decision.
I'm afraid I don't know enough to supply a useful patch here. I'm mostly
articulating these issues in the hope that some simple solution to some of it
may occur to someone who knows more than I do.
Two things. First you can put custom file context in
Which will survice a policy update.
Also genhomedircon should be picking up the fact that you have users in the
/guest directory and label it correctly. Do you have users in your passwd files
with /guest as the root of the home dir?
You should see definition in file_contexts.homedirs?
Theoretically Issue 1 and 2 should be handled by this. Issue three should not
happen. Do you have a mismatch between the default kernel and the policy?
Now that I think about it, genhomedircon probably *is* working for the home
directories. I'm unclear when genhomedircon runs, however, and that would be
useful to know.
I'll try file_context.local for case 2 and see how that goes.
Issue three definitely *does* happen. Now that you raise the kernel versioning
issue, it occurs to me that in many of the cases where I have observed this
problem, the selinux policy and the kernel have been upgraded simultaneously by
yum and the selinux policy postinstall then failed as described in the other bug
that I filed. Not sure if that is related or not.
Genhomedircon is run when you upgrade the policy.
Also if you are customizing policy-sources it is also run
Any update on this bug?
I've made some definite progress using file_context.local; that was very
helpful. There remains the issue of "treat this directory like that one" for Xen
installs, but I propose that we should handle that with a separate bug report.
Given which, I'm content to close this bug.