Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234085 - Multiple same specifications produced by genhomedircon
Summary: Multiple same specifications produced by genhomedircon
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 6
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-26 22:19 UTC by mgm
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-17 16:09:22 UTC

Attachments (Terms of Use)
file_contexts.homedirs (deleted)
2007-04-12 20:48 UTC, mgm
no flags Details

Description mgm 2007-03-26 22:19:40 UTC
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):

How reproducible:
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...
2. Reboot
3. Watch console output for warning message below
Actual results:
"multiple specifications for /export/home/..." warning displayed on console

Expected results:
No error/warning message

Additional info:
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'.

Comment 1 Daniel Walsh 2007-04-11 18:11:10 UTC
Why not just bind mount /home on /export/home and not have to change the
homedirectories.  That would make SELinux happier.


Comment 2 mgm 2007-04-11 21:25:19 UTC

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 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?


Comment 3 mgm 2007-04-11 21:33:39 UTC

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.


Comment 4 Daniel Walsh 2007-04-12 12:52:32 UTC
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?

Comment 5 mgm 2007-04-12 20:48:12 UTC
Created attachment 152505 [details]

Comment 6 mgm 2007-04-12 20:48:59 UTC

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.


Comment 7 mgm 2007-04-12 21:01:35 UTC
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...

Comment 8 Daniel Walsh 2007-04-12 21:07:41 UTC
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
been fixed.

Comment 9 mgm 2007-04-13 19:10:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.