Bug 163668

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
/guest.

Problem: restorecon -R / screws up the file contexts on these non-conventional
directories.

Exacerbation 1: if I edit the file_contexts file, then updates of the selinux
policy fail.

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
stale.

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.