Bug 962214 - SELinux is preventing /usr/sbin/useradd from write access on the directory /.
SELinux is preventing /usr/sbin/useradd from write access on the directory /.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-12 12:10 EDT by Dean Hunter
Modified: 2013-05-17 10:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-17 10:32:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dean Hunter 2013-05-12 12:10:35 EDT
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
Comment 1 Dean Hunter 2013-05-12 12:32:51 EDT
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.
Comment 2 Dean Hunter 2013-05-12 13:37:52 EDT
[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 ~]#
Comment 3 Daniel Walsh 2013-05-13 09:00:15 EDT
If you put the machine in permissive mode, what AVC's do you get.
Comment 4 Daniel Walsh 2013-05-13 09:03:01 EDT
mgrepl any reason we did not remove

optional_policy(`
	usermanage_run_useradd(unconfined_t, unconfined_r)
')
Comment 5 Miroslav Grepl 2013-05-13 10:04:42 EDT
Yes, I think there was a reason. Let me to find a bug/comment.
Comment 6 Miroslav Grepl 2013-05-13 10:15:01 EDT
AFAIK we have been discussing it on fedora-selinux list also with Dominick.

Maybe we could try to remove it in Rawhide.
Comment 7 Dean Hunter 2013-05-13 10:37:49 EDT
[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 ~]#
Comment 8 Daniel Walsh 2013-05-13 11:13:55 EDT
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?
Comment 9 Ian Kent 2013-05-13 22:25:39 EDT
(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
Comment 10 Ian Kent 2013-05-13 22:31:18 EDT
(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.
Comment 11 Dean Hunter 2013-05-14 10:52:28 EDT
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?
Comment 12 Ian Kent 2013-05-15 01:04:41 EDT
(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
Comment 13 Dean Hunter 2013-05-15 10:20:14 EDT
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?
Comment 14 Ian Kent 2013-05-16 21:20:43 EDT
(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.

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