Created attachment 599050 [details]
File: description

Do you know what you were doing?

DOes useradd attempt to create the /run/user directory?

This problem happens on fedora 17 when creating user with home directory in /run.
e.g.: 'useradd test -d /run/test' leads to this problem.

There is a SETroubleshoot detail in english:

SELinux is preventing /usr/sbin/useradd from write access on the directory /run.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that useradd should be allowed write access on the run 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                unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:var_run_t:s0
Target Objects                /run [ dir ]
Source                        useradd
Source Path                   /usr/sbin/useradd
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           shadow-utils-4.1.4.3-14.fc17.x86_64
Target RPM Packages           filesystem-3-2.fc17.x86_64
Policy RPM                    selinux-policy-3.10.0-137.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.4.4-5.fc17.x86_64 #1
                              SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    Mon 30 Jul 2012 04:10:10 PM CEST
Last Seen                     Mon 30 Jul 2012 04:10:10 PM CEST
Local ID                      a2c60538-3a33-41ce-9510-7159c5a2a045

Raw Audit Messages
type=AVC msg=audit(1343657410.310:87): avc:  denied  { write } for  pid=1607 comm="useradd" name="/" dev="tmpfs" ino=6358 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=dir


type=SYSCALL msg=audit(1343657410.310:87): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=7fff359037e5 a1=0 a2=7f3f58bca730 a3=6165726373662f72 items=0 ppid=1558 pid=1607 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null)

Hash: useradd,useradd_t,var_run_t,dir,write

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied


audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied





As /run is tmpfs, this is not a good idea to put $HOME there.

Why are you putting the user account into /run?

If you want to do this you can add the rule as specified in the alert.  This does not seem to be something we want to allow out of the box.

# grep useradd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

*** Bug 901947 has been marked as a duplicate of this bug. ***