Description of problem:
Multiple specifications for /export/home/... in
/etc/selinux/targeted/contexts/files/file_contexts.homedirs (generated by
genhomedircon). File homedir_template in the same directory has not been
modified. file_contexts.homedirs has three groups of entries -- the first two
are identical and are for /export/home/..., while the third is for /home/...
Version-Release number of selected component (if applicable):
Reproducible. Hand-editing of file_contexts.homedirs is useless because it is
regenerated at reboot (or any time genhomedircon is run).
Steps to Reproduce:
1. See description of how users were added below...
3. Watch console output for warning message below
"multiple specifications for /export/home/..." warning displayed on console
No error/warning message
Possible relevant info: This system is used as a file server for users' home
directories. Home directories are created under /export/home, and exported to
client machines on the network via NFS. NIS is used for for logins, etc.,
autofs for automounting... As such, before creating user accounts after initial
install, the default location of HOME_DIR was changed with 'useradd -D -b
/export/home'. Then users were created with 'useradd.' Finally, after
NIS/NFS/autofs was set up, users' home dir location in /etc/passwd was changed
to /home using 'usermod -d /home'.
Why not just bind mount /home on /export/home and not have to change the
homedirectories. That would make SELinux happier.
Yes, bind-mounting would work. However, that would make the server machine,
which is also technically a client in my architecture, a special case. Autofs
maps would have to be different (bind mount for server, NFS for clients), etc.
Since my server also provides its autofs maps to the clients via NIS, this would
be more trouble than the way I'm already doing it. (I suppose my auto.xxx could
be a scripts that figure out whether the machine is client or server, and mount
via bind or nfs accordingly...)
But is there a reason that SELinux should be unhappy with what I've done?
I just re-read your comment, and I may have misunderstood you the first time. I
think you probably meant to have the users' actual files reside in /home on the
server, bind mount that on /export/home, then export /export/home. I took it
the other way at first, i.e. files reside in /export/home, bind-mount
/export/home on /home on the server, nfs-mount server's /export/home on /home on
the clients. However, I think my reply still applies -- this arrangement would
create a different autofs situation for the server vs the clients, and I was
trying to keep the machines as parallel as possible.
mgm, the problem is that genhomedircon is trying to setup the correct labeling
on the homedirs. And is failing with autofs. I am trying to figure out the
best way to handle this. I guess the best idea is for me to try to setup your
environment and play around with it. But how does the application genhomedircon
figure out the location of the homedirs? Or would the best solution be to have
a flag that shuts down genhomedircon after you set it up correctly?
Created attachment 152505 [details]
Flag would be OK, I guess.
Would having autofs OFF when genhomedircon runs keep it from getting confused?
If so, can it shut down the autofs service and then restart it? Maybe this is
more of a problem than a solution, though, if the system is up and running with
users logged in at the time...
Or, perhaps if genhomedircons is having trouble figuring out where the "real"
location of the homedirs is, it could be (optionally) specified or forced in
Or, looking at the file_contexts.homedirs (attached) that genhomedircon produces
on my system, I end up with two groups of specs where the value of HOME_DIR in
the homedir_template was replaced with '/export/home' and one group where it was
replaced with '/home'. I'm assuming that one group for '/export/home' and one
for '/home' would be fine, but that the extra '/export/home' is causing the
warning messages. So could genhomedircom avoid producing duplicates somehow by
not substituting the same thing twice for HOME_DIR?
By the way, if these ideas are idiotic, or if I'm way off about how
genhomedircon even works, please forgive. Also, any files or captures you need
from me to help with debug, I'll be happy to provide, and any tests you'd like
to perform (incl. trying out code) just let me know.
Oh, for cryin' out loud! I guess I lied... I could have sworn when I posted
this bug originally that my file_contexts.homedirs had two blocks for
/export/home and one for /home. But now when I look at the attachment I just
added I see only one for each. I guess I'm losing my mind. Sorry...
So everything looks ok now. The reason it is working is, you must have a user
listed some where with /export/home as his home dir, which will cause it to be
labeled correctly. Then the other users have /home so they are labeled
correctly. In the future we will have different users with different users home
directory labels. Say a guest_home_dir_t and a user_home_dir_t. This will not
work correctly, on your system since user dwalsh home dir would be listed as
/home/dwalsh but actually be /export/home/dwalsh.
As far as the double entries this could have been caused by a bug that has now
Yep, looks fine now. I'm pretty stumped, because I do believe that (at one
time) I had double entries for /export/home. Maybe if I get some time this
weekend I'll install plain FC6 with no updates on a canary system and see if I
can reproduce the double entry thing. Mostly for my own sanity, because if it's
fixed it's fixed.
Thanks for your help. Based on your comment #8, it seems like I should rethink
my architecture a little bit.