During QA of system-config-users, we found an (arguably artificial) corner case where libuser failed to create a home directory because the parent directory has mode 000 -- a simple mkdir works there because root usually has CAP_DAC_OVERRIDE, but something SELinux-related that libuser attempts to do, fails.

+++ This bug was initially created as a clone of Bug #599214 +++
[...]
--- Additional comment from omoris on 2010-08-30 16:29:41 EDT ---

Nils, here's another problem:

1. mkdir /tmp/x
2. chmod a-rwx /tmp/x
3. s-c-users -> add user 'y' -> set home dir to /tmp/x/y

It will succeeded:

# getent passwd y
y:x:504:504::/tmp/x/y:/bin/bash

But no homedir is created and s-c-users prints the following traceback:

# system-config-users 
Traceback (most recent call last):
  File "/usr/share/system-config-users/userWindow.py", line 408, in on_userWin_ok_button_clicked
    self.parent.ADMIN.addUser(userEnt, mkhomedir = True)
RuntimeError: couldn't determine security context for `/tmp/x/y': No such file or directory

# rpm -q system-config-users
system-config-users-1.2.104-1.el6.noarch
[...]
--- Additional comment from nphilipp on 2010-09-08 05:01:21 EDT ---

I've added fixes to the upstream repo to deal better with homes in automounted directories:


commit 5fcefe54e19760559ef425205c434e94f8bbd524
Author: Nils Philippsen <nils>
Date:   Tue Sep 7 17:39:11 2010 +0200

    cope better with deleting auto-mounted home directories
    
    Auto-mounted home directories cannot be removed normally, the automounter
    needs to be reconfigured for that. In that case, remove the contents and
    change ownership back to root.


commit d76a8c7dcde7a9309676f25f13ff0961f7a169fc
Author: Nils Philippsen <nils>
Date:   Tue Sep 7 16:55:33 2010 +0200

    Attempt to mkdir home directory instead of using os.access().
    
    The access system call may erroneously assume that a directory is writable
    (e.g. in autofs roots, procsfs, sysfs, ...). Rather than special-casing
    affected file systems, simply try to create the home directory -- libuser
    copes well with existing directories.

This does not yet cover the (arguably artificial) case described in comment #13, where libuser fails to create the home directory:

root@gibraltar:~> mkdir /tmp/x
root@gibraltar:~> chmod 000 /tmp/x
root@gibraltar:~> luseradd -d /tmp/x/y y
Error creating /tmp/x/y: couldn't determine security context for `/tmp/x/y': No such file or directory.
root@gibraltar:~> getent passwd y
y:x:501:502:y:/tmp/x/y:/bin/bash
root@gibraltar:~> ls /tmp/x
root@gibraltar:~> mkdir /tmp/x/y
root@gibraltar:~> ls /tmp/x
y
root@gibraltar:~>

I'm not sure whether this issue lies in libuser or in some SELinux code, though. S-c-users could only catch the error at this point and bail out.