SELinux is preventing the gdm-binary from using potentially mislabeled files (). Source Context: system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context: system_u:object_r:tmp_t:s0 Target Objects: None [ dir ] avc: denied { setattr } for comm=gdm-binary dev=dm-3 name=.X11-unix pid=2479 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=dir tcontext=system_u:object_r:tmp_t:s0 Also: SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "read" to (home_root_t). Source Context: system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 Target Context: unconfined_u:object_r:home_root_t:s0 Target Objects: None [ file ] avc: denied { read } for comm=X dev=dm-3 egid=0 euid=0 exe=/usr/bin/Xorg exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=fonts.dir pid=2992 scontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=unconfined_u:object_r:home_root_t:s0 tty=tty7 uid=0 SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "write" to (home_root_t). Source Context: system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context: system_u:object_r:home_root_t:s0 Target Objects: None [ dir ] avc: denied { write } for comm=gdm-binary dev=dm-3 egid=501 euid=501 exe=/usr/sbin/gdm-binary exit=-13 fsgid=501 fsuid=501 gid=501 items=0 name=jkeating pid=3021 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=501 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=501 tclass=dir tcontext=system_u:object_r:home_root_t:s0 tty=(none) uid=501 Finally SELinux is preventing gdm-binary (xdm_t) "link" to (kernel_t). Source Context: system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context: system_u:system_r:kernel_t:s0 Target Objects: None [ key ] avc: denied { link } for comm=gdm-binary pid=2314 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key tcontext=system_u:system_r:kernel_t:s0
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.
luseradd does it too, coming from libuser.
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
Thanks, fixed in libuser-0.56.6-1.fc[89]. Jesse, are you going to add this package to Fedora 8, or should I add it to bodhi as well?
I think this should be in F8 final, so that users created immediately after installation get the correct SELinux contexts for their home directories.
I'm going to tag it for the release. Will need to do an install with it and verify things look good, setting to MODIFIED.
Miloslav, How did you fix this?
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.