Description of problem: With auto-mount of NFS home directories configured I can not add a new local user. Version-Release number of selected component (if applicable): Installed Packages selinux-policy.noarch 3.12.1-42.fc19 @fedora selinux-policy-devel.noarch 3.12.1-42.fc19 @fedora selinux-policy-doc.noarch 3.12.1-42.fc19 @fedora selinux-policy-targeted.noarch 3.12.1-42.fc19 @fedora How reproducible: Consistent Steps to Reproduce: 1. Add a new local user from Gnome settings Actual results: SELinux alert message pop-up Expected results: No alerts and user added with a new initialized home directory on the NFS mount Additional info: SELinux is preventing /usr/sbin/useradd from write access on the directory /. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that useradd should be allowed write access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep useradd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:useradd_t:s0 Target Context system_u:object_r:autofs_t:s0 Target Objects / [ dir ] Source useradd Source Path /usr/sbin/useradd Port <Unknown> Host fedora19.hunter.org Source RPM Packages shadow-utils-4.1.5.1-5.fc19.x86_64 Target RPM Packages filesystem-3.2-10.fc19.x86_64 Policy RPM selinux-policy-3.12.1-42.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora19.hunter.org Platform Linux fedora19.hunter.org 3.9.1-301.fc19.x86_64 #1 SMP Wed May 8 18:02:34 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-05-12 10:55:49 CDT Last Seen 2013-05-12 10:55:49 CDT Local ID 3a9b94ca-c0dd-4fef-89ed-45c3535714c7 Raw Audit Messages type=AVC msg=audit(1368374149.171:445): avc: denied { write } for pid=2144 comm="useradd" name="/" dev="autofs" ino=17330 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:object_r:autofs_t:s0 tclass=dir
What is the sequence of commands to add a new user from the command prompt? It is easier for me to repeat a test using scripts and I am not familiar with the commands creating, modifying, and deleting local users.
[root@fedora19 ~]# useradd test --user-group useradd: cannot create directory /home/test [root@fedora19 ~]# ausearch --message AVC --start recent ---- time->Sun May 12 12:16:12 2013 type=SYSCALL msg=audit(1368378972.858:477): arch=c000003e syscall=83 success=no exit=-13 a0=7f34898eb320 a1=0 a2=7f348880b798 a3=5f656d6f685f7265 items=0 ppid=1988 pid=2240 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=2 tty=pts0 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1368378972.858:477): avc: denied { write } for pid=2240 comm="useradd" name="/" dev="autofs" ino=19563 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:autofs_t:s0 tclass=dir [root@fedora19 ~]# getsebool use_nfs_home_dirs use_nfs_home_dirs --> on [root@fedora19 ~]# ls -dZ /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home [root@fedora19 ~]# findmnt TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/fedora_fedora19-root ext4 rw,relatime,seclabel,da ... ├─/misc /etc/auto.misc autofs rw,relatime,fd=6,pgrp=1 ├─/net -hosts autofs rw,relatime,fd=12,pgrp= └─/home /etc/auto.home autofs rw,relatime,fd=18,pgrp= └─/home/local host.hunter.org:/srv/nfs/home/local nfs4 rw,relatime,vers=4.0,rs [root@fedora19 ~]# cat /etc/auto.home # # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # Details may be found in the autofs(5) manpage # * -fstype=nfs4 host.hunter.org:/srv/nfs/home/& [root@fedora19 ~]# [root@host ~]# mkdir /srv/nfs [root@host ~]# cp -cfpr /home /srv/nfs .... [root@host ~]# ls -dZ /srv drwxr-xr-x. root root system_u:object_r:var_t:s0 /srv [root@host ~]# ls -Z /srv drwxr-xr-x. root root system_u:object_r:var_t:s0 nfs [root@host ~]# ls -Z /srv/nfs drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home drwxr-xr-x. qemu qemu unconfined_u:object_r:var_t:s0 ISO drwx------. root root system_u:object_r:var_t:s0 lost+found drwxr-xr-x. 128000001 128000001 unconfined_u:object_r:var_t:s0 Shared [root@host ~]# ls -Z /srv/nfs/home drwxr-xr-x. local local unconfined_u:object_r:user_home_dir_t:s0 local drwx------. root root system_u:object_r:lost_found_t:s0 lost+found [root@host ~]# ls -Z /srv/nfs/home/local drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Desktop drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Documents drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Downloads drwxr-xr-x. local local unconfined_u:object_r:audio_home_t:s0 Music drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Pictures drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Public drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Templates drwxr-xr-x. local local unconfined_u:object_r:user_home_t:s0 Videos [root@host ~]# cat /etc/exports /srv/nfs/home *.hunter.org(rw,sync) /srv/nfs/ISO *.hunter.org(rw,sync) /srv/nfs/Shared *.hunter.org(rw,sync) [root@host ~]#
If you put the machine in permissive mode, what AVC's do you get.
mgrepl any reason we did not remove optional_policy(` usermanage_run_useradd(unconfined_t, unconfined_r) ')
Yes, I think there was a reason. Let me to find a bug/comment.
AFAIK we have been discussing it on fedora-selinux list also with Dominick. Maybe we could try to remove it in Rawhide.
[root@fedora19 ~]# getenforce Enforcing [root@fedora19 ~]# setenforce 0 [root@fedora19 ~]# getenforce Permissive [root@fedora19 ~]# useradd test --user-group useradd: cannot create directory /home/test [root@fedora19 ~]# ausearch --message AVC --start recent ---- time->Mon May 13 09:36:02 2013 type=SYSCALL msg=audit(1368455762.130:430): arch=c000003e syscall=83 success=no exit=-13 a0=7f305baa2320 a1=0 a2=7f3058c14798 a3=5f656d6f685f7265 items=0 ppid=1252 pid=1438 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=1 tty=pts0 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1368455762.130:430): avc: denied { create } for pid=1438 comm="useradd" name="test" scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:autofs_t:s0 tclass=dir type=AVC msg=audit(1368455762.130:430): avc: denied { add_name } for pid=1438 comm="useradd" name="test" scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:autofs_t:s0 tclass=dir type=AVC msg=audit(1368455762.130:430): avc: denied { write } for pid=1438 comm="useradd" name="/" dev="autofs" ino=17990 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:autofs_t:s0 tclass=dir [root@fedora19 ~]#
Well it looks like something else besides SELinux is blocking you from doing what you want to do. useradd test --user-group useradd: cannot create directory /home/test In permissive mode. I want to ask the autofs guys if this should be supported?
(In reply to comment #8) > Well it looks like something else besides SELinux is blocking you from doing > what you want to do. > > useradd test --user-group > useradd: cannot create directory /home/test > > > In permissive mode. > > I want to ask the autofs guys if this should be supported? Even if selinux didn't catch this the kernel would deny it later on. I'm having difficulty understanding how anyone could expect this to work. First this is trying to create the mount point directory, not the directory at the location that is to be mounted. Second, to automount the location it either needs to be mounted from an NFS server or, if local, bound to the mount point directory. In both cases the location to be mounted must already exist in order to be mounted or bound. So there are several places where the kernel with return an error in this case, selinux, the autofs kernel module, and if that's not enough the mount(2) system call will also return a fail because the mount location doesn't exist. Ian
(In reply to comment #2) > [root@fedora19 ~]# useradd test --user-group > useradd: cannot create directory /home/test > Maybe there's a bug in useradd or the message is incorrect. It shouldn't be trying to create a home directory unless the -m option is given. And, as I say, in order for this to work the home directory must either already be created and exported by the NFS server or the local directory must already exist.
Ian, I am just fumbling my way through this, trying to learn as best I can. Can you recommend a "how to" documentation source? I have read reference manuals on each component: exporting an NFS directory, auto-mounting user home directories, creating new users; but I am missing something that teaches me how to use all the parts together. And the error messages are not particularly helpful. Or put another way, where would I find documentation that explains your two comments?
(In reply to comment #11) > Ian, I am just fumbling my way through this, trying to learn as best I can. > Can you recommend a "how to" documentation source? I have read reference > manuals on each component: exporting an NFS directory, auto-mounting user > home directories, creating new users; but I am missing something that > teaches me how to use all the parts together. And the error messages are not > particularly helpful. > > Or put another way, where would I find documentation that explains your two > comments? Yes, it can be confusing and this description will probably just make matters worse but here goes. I don't know of any documentation that specifically describes this situation but the basic difficulty is fairly straight forward. The automount utility, in the simplest terms, essentially calls the mount utility on behalf of the user. The mount utility requires that the mount point directory and the mount location to already exist and there's no way to avoid that. So, in your case we have: 1) /srv/nfs/home exported on the NFS server, so no additional export entries will be needed for home directories created within this directory. 2) Your using a wildcard map, so the map doesn't need to be updated to automount a new home directory. 3) You want to run useradd to populate an automounted home directory with the default profile. The last point is where the problems are. 1) Adding users on individual systems can lead to user id duplication. 2) The directory used for the home directory must already exist when automounting it. 3) If your creating the user account on a machine other than the machine hosting the NFS home directories then the root user on the client machine needs root access via NFS to the machine with the home directories. This last point is generally sufficient reason to never create user accounts on client machines quite apart from point 1 about user id conflicts. Usually, when using an NFS server for centralized home directories some centralized user management method is also used, such as LDAP or NIS. The central management of user accounts deals with point 1 but also deals with point 3 since user accounts are created on the machine exporting the home directories. Using NIS for central user account management is the simplest but is not recommended unless you are in an isolated network, ie. not exposed to the wider internet. LDAP, while somewhat more difficult to manage, is what people are moving to. Maybe you could start with NIS and migrate to LDAP once things have settled. One NIS hotwo is here: http://www.tldp.org/HOWTO/NIS-HOWTO The book "Managing NFS and NIS" is quite old and a bit out of date but is useful: http://shop.oreilly.com/product/9781565925106.do Note that autofs maps may be stored centrally as well, in both NIS and LDAP, so automount map changes are automaticaly seen on clients. Now, back to the original problem. Since we need to manage user accounts centrally to avoid uid conflicts and have admin level access to the home directory when creating it accounts need to be created on the machined hosting the user home directories (well they do if you haven't written a provisioning sub-system that can handle it otherwise). So, in your case, using NIS you would do something like: On the chosen central machine (as root): 1) Create user home directory within the exported directory containing the home directories. 2) Use whatever utility you wish to provision the new user, account, useradd in this case. 3) Run make in the appropriate NIS directory to update its data and push the update to any NIS slaves. Usually you would have at least one slave NIS server in case the master is not available for some reason but that is not mandatory. Now, the question remaining is whether useradd will be happy with automounting the new user home directory when it is run, since we want the automount home directory path to be used when creating the user account and not the NFS export path. In theory that should work ok because, since the NFS exported directory is local, automount should perform a bind mount not an NFS mount so root access will be ok. Then there's the question of useradd changing the ownership of the bound mount actually changing the ownership of the correct directory. You'll need to check that and adjust it if need be but it should work as expected. The situation is similar without NIS except that you will need to manually alter /etc/passwd and /etc/group on your clients based on what useradd has done on the central machine. Note that for consistent NFS access user uid and gid numbers need to be consistent on all your clients, as of course do file ownership and modes of files within the exported file systems. I really don't think you can get away from using a central machine for user provisioning. No doubt this has only added to the confusion and I'm sorry in advance for that, but I have tried to give you something to help. Ian
Thank you for taking the time to write this explanation. I really appreciate your efforts. In fact, I am using FreeIPA (which includes LDAP) for centralized administration of users. And the next step is to move the auto-mount configuration to FreeIPA. The FreeIPA Guide cautions checking that the auto-mount configuration is working correctly first. I saw things I did not understand, like the change in the SELinux attributes (https://bugzilla.redhat.com/show_bug.cgi?id=956823) and the creation of new user home directories, and thought that must be the reason for such a caution. I guess I should know better by now. Again, I thank you. It all makes perfect sense now. As for the disposition of this bug report, is there some way we can use my experience to better illuminate the path for the next rookie to come this way?
(In reply to comment #13) > > Again, I thank you. It all makes perfect sense now. > > As for the disposition of this bug report, is there some way we can use my > experience to better illuminate the path for the next rookie to come this > way? A knowledge base article might be a good idea but I don't have access to that system and, TBH, I don't have time either. Perhaps if you had logged this via support (which is the way problems should come to us) they would be able to direct it to someone who could do something like that.