These are all caused because homedirs created by system-config-users is labeling
the homedir as (home_root_t). They should instead be (unconfied_home_dir_t).
About to test if this can be caused by adding users in firstboot.

This is going to be anything using libuser to add users. shadow-utils was
changed to explicitly set file contexts when creating the user home directory,
but libuser was never made to do that. In the past, this worked because we had
a transition rule from home_root_t -> user_home_dir_t. Now that the transition
rule isn't there (to support multiple roles?), the home dir isn't getting
created with the right context in apps that use libuser.
This will impact:
1) system-config-users
2) firstboot
3) Addition of users in kickstart

I tested with the new libuser set and now the homedirs are being created as
unconfined_u:object_r:unconfined_home_dir_t which seems correct. Closing the
bug, but I'm sure others would still like to review the change.

Ok I tested this out and it seems to work well.
One thing we probably want to add, is the equivalent of useradd -Z which allows
you to select SELinux users.
I changed the default SELinux user and system-config-users labeled the homedirs
and all of its subdirs correctly. Good job

(In reply to comment #9)
> One thing we probably want to add, is the equivalent of useradd -Z which allows
> you to select SELinux users.
Speaking of that, I guess certain SELinux users map to certain SELinux contexts
for the home directory -- shouldn't the -Z option be enough or isn't that a 1:1
(n:1) mapping?
Either way, is there an easy way to find out which SELinux users exist and which
is the default? It would be good if system-config-users allowed the admin to set
this.

There is a python binding semanage that would allow you to do this.
/usr/lib/python2.5/site-packages/seobject.py
Is a python wrapper on semanage that allows you to get this info
semanage user -l
Is the command line interface, for this.

Dan,
libuser uses matchpathcon() to determine the context to use for each created file.
WRT SELinux users, libuser as such (as opposed to luseradd and partly to the
Python bindings) is really a "writable nss_*", ideally the libuser interfaces
should be independent from other user-related configuration.
* If a UNIX user is assigned a non-default SELinux user, will matchpathcon()
automatically return the right file contexts for files in the user's home
directory?
* Does the UNIX user have to be created before creating the SELinux user mapping?

Yes the steps are to create a login user to SELinux user mapping.
Which from the command line is
semanage linux -a -s SELINUX_USER USERNAME
At that point you should be able to add the user and copy the skel using
matchpathcon.
In the command line tools there is a catch 22 though. The tools will block you
from doing the user mapping until the Linux USERNAME exists. So it used to be
useradd dwalsh
semanage linux -a -s xguest_u dwalsh
restorecon -R -v ~dwalsh
I hope if you call the semanage calls directly you can avoid the check for
existing username.