Red Hat Bugzilla – Bug 146337
genhomedircon needs better handling of subdirs
Last modified: 2007-11-30 17:10:59 EST
Forcing /home (or whatever useradd defaults to) into prefixes can have
a very bad side effect if your actual home dir roots are subdirs of
/home. You end up with file contexts such as:
/home/foo -d system_u:object_r:home_root_t
/home -d system_u:object_r:home_root_t
/home/foo/[^/]+ -d system_u:object_r:user_home_dir_t
/home/[^/]+ -d system_u:object_r:user_home_dir_t
So you see, /home/foo ends up labeled as user_home_t, not home_root_t,
and things don't quite work as expected.
Sure enough, having a single /home/foo is easy, and you can simply
adjust useradd's default to match that, but if you have many, no
default would be appropriate, and you then have to be careful to never
choose a dir that has any home dir as a subdir. In fact, if you have
home dir roots that are subdirs of each other, things get
unpredictable, since the order of the hash keys is unpredictable.
They should be sorted from outermost to innermost to get the correct
behavior and, even then, you have to group all above entries per
HOME_DIR before all such entries for nested homedirs, otherwise you
get incorrect labels.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create a user with home in /foo/bar
2.Create another user with home in /foo/baz/bad
Actual Results: /foo/baz will have conflicting rules.
Expected Results: They should be ordered properly, so as to be
We have rewritten genhomedircon in rawhide to better handle this situation.