Description of problem:
When a user account is created and the -m option is used to create
the user's home directory, the user part of the SELinux context
is the same as the user who created the account, rather than being
the selinux user for the new user. A restorecon will change it to
what I would normally expect it to be.
Version-Release number of selected component (if applicable):
RHEL5 Beta 2 with these policy RPMs from Dan's people page:
Steps to Reproduce:
1.run "useradd -m <login>"
2.run "ls -lZ /home/<login>" to get the context
3.run "restorecon -R -v ~<login>"
4. run "ls -lZ /home/<login>" again to get the context
After the first 'ls', the context is:
After the restorecon, the context is:
I would expect that useradd would create a home directory with
the context that the policy would restore with a restorecon.
For example, user_u with user_home_dir_t instead of staff_u with
I'm not sure why the restorecon changed the directory to be ranged.
There isn't an entry for this login in the seusers file and the default
user is "__default__:user_u:s0".
I picked "selinux-policy" for the component so Dan would see the
bugzilla although the fix is probably in useradd.
This is likely a bug in shadow-utils. It should probably be doing a setfilecon
on the homedir that its creating in create_home().
What version of shadow-utils you use? I can't reproduce it.
You need to newrole such that you have staff_u in your context before running
the useradd program.
I'm running the shadow-utils from beta2 shadow-utils-4.0.17-7.el5.
My system was installed using the kickstart script that we're using for
the lspp project, described here:
You need to be running the MLS policy.
I just reproduced it again:
[ljk@kipper ~]$ /bin/su -
[root@kipper ~]# useradd -m normalljk2
[root@kipper ~]# ls -lZ /home/normalljk
[root@kipper ~]# ls -ldZ /home/normalljk2
drwx------ normalljk2 normalljk2 staff_u:object_r:home_root_t:SystemLow
[root@kipper ~]# restorecon -R -v ~normalljk2
restorecon reset /home/normalljk2 context
[root@kipper ~]# ls -ldZ /home/normalljk2
drwx------ normalljk2 normalljk2
Created attachment 142460 [details]
Patch to change the context of a made homedir to matchpathcon() result
This should fix the problem. I haven't tested on MLS, but it's so simple it's
hard to believe there's a bug there.
Note that if it fails it just continues, as this is what chown/chmod do in the
same function (and in non-MLS that's almost certainly the right thing to do as
Does it generate any avc messages? Could you create an init script that does a
useradd, relabel it initrc_exec_t and then service start it, to see if any avc
messages are generated?
This patch has "extra" fixing that is not strictly needed. But otherwise looks
exactly as expected. Looks safe to build into rawhide for testing purposes.
I'm not sure who Dan was asking and whether he was looking for something
before or after the patch but I looked at the audit logs from when I
did my experiment above (no patch) and I have no avc denies from useradd.
I get lots of avc granted messages for setfscreate.
shadow-utils-4.0.17-10.el5 was built to solve this problem.
Is there a place I can get the rpm to give it a try or do I need to wait
until the next milestone?
Sorry Linda, I thought I'd already posted this...
I got a warning when I installed the rpm that it had moved /etc/login.defs but
I ignored so I ended up without a file. useradd silently fails in that case,
but I found this message in /var/log/secure:
Nov 30 17:47:52 kipper useradd: cannot open login definitions
/etc/login.defs [No such file or directory]
I got no messages from the command though so that seems weird, but
probably unrelated to these changes.
Anyway, I fixed my system so useadd works but I'm still seeing the same
behavior regarding the context of the new home directory. I'm logged
in as a non-root user, do an su, then a newrole to become sysadm_r, then
[root@kipper ~]# useradd -m antill
[root@kipper ~]# ls -ldZ /home/antill
drwx------ antill antill staff_u:object_r:user_home_dir_t:SystemLow /home/antill
[root@kipper ~]# restorecon -R -v ~antill
restorecon reset /home/antill context
[root@kipper ~]# ls -ldZ /home/antill
drwx------ antill antill user_u:object_r:user_home_dir_t:SystemLow-SystemHigh
Notice the context changes from staff_u to user_u and from SystemLow to
SystemLow-SystemHigh. The type field stays the same and looks right.
user_u looks right after the restorecon but I don't know why it ranged
the directory. The default user in seusers is:
So I think the net result is that setting the type part of the context
was fixed but not the user field, and I don't know why restorecon
ranged the directory, but that almost seems like a separate issue.
Are all home directories supposed to be ranged?
I should add that I did the above with the namespace support turned off
in /etc/security/namespace.conf. I can't do a newrole with the latest
newrole rpm when its enabled but that's a separate issue too. Just
wanted to point this out in case you try it and get different results.
Ok, so without the patch it was:
...and after matchpathcon() it is:
...which is better. But after restorecon (in either case) it is:
...so I'm guessing either restorecon isn't doing just a matchpathcon(), or there
is some policy difference between the context useradd runs in and the context
restorecon runs in. Can you provide the output of:
Your summary is correct. This is what I see from matchpathcon.
Your "foo" request was probably just an example but I actually had created a
foo account earlier and had done as semanage on it. Since there's a listing for
"foo" in seusers "foo:staff_u:s0-s15:c0.c1023", the matchpathcon
output for it looks reasonable. I didn't do an semanage for the
A couple comments:
1) I don't believe that useradd can do the right thing here in general for
labeling of home directories, because you have to first add the Linux user id
via useradd, then use semanage to map the Linux user id to a SELinux user and
range, and it isn't until that second step that SELinux is going to know how to
label that home directory (and you have to apply restorecon after that point).
Sure you can handle the case where you just are defaulting to user_u, but that
is just one case. So a separate restorecon of the home directory is always
going to be necessary unless of course one creates a new UI that encapsulates
the entire sequence for adding a user and defining his authorized role set
(SELinux user) and range.
2) The home directory level wouldn't come from the user's clearance anyway - it
is just coming from homedir_template in policy and is always the same for
everyone. Then the home directory gets polyinstantiated by pam_namespace to
contain multiple single level directories. So if you want the top-level
container directory (the one that just holds the per-level directories) to be
SystemLow, just change homedir_template and rebuild your policy. I suspect the
range comes from the old TCS approach of using ranged directories to provide
"multi-level" directories in the absence of polyinstantiation.
I don't understand why it doesn't/can't work in the default case. Makes
me wonder what the behavior is right now with the strict policy since more
than just the level isnt' right.
It would be nice if we could create the selinux user first and then tell
useradd to associate the linux user with it, or to use the default selinux
And if I could get polyinstantiation to work I'd be a real happy camper.
The same issue exists in strict policy, and is even described in SELinux
documentation. Adding Linux users is a separate action from authorizing them
for SELinux contexts, and labeling of their home directories can only occur
after the latter. We could drop the requirement from semanage (seobject.py)
that the Linux user already be defined, but that was intended to prevent
mistakes (e.g. typo in the username) - it is a validity check on the input.
Optionally dropping the check for a linux user may make sense - it would help
useradd and perhaps sharing mappings between systems.
With that change useradd could make the correct semanage call first and then
create the user. Of course to be truly useful useradd would need flags to set
Fixed in shadow-utils-4.0.17-11.el5
QE ack for RHEL5.
A package has been built which should help the problem described in
this bug report. This report is therefore being closed with a resolution
of CURRENTRELEASE. You may reopen this bug report if the solution does
not work for you.