Description of problem: When using pam_mkhomedir.so to automatically create home directories on first login, the newly created home directory and all its contents are created with SELinux label 'home_root_t'. Version-Release number of selected component (if applicable): selinux-policy-3.10.0-149.fc17.noarch How reproducible: Always Steps to Reproduce: 1. Configure the host to use pam_mkhomedir.so in system-auth and password-auth 2. Create a user without creating its home directory, or remove the home directory of an existing user 3. Log in as the user. The home directory will be automatically created. NOTE: At this point I've only tested this with ssh logins. Actual results: The user's home directory and all contents have SELinux label 'home_root_t' Expected results: The user's home directory and all contents are created with the correct SELinux labels. Additional info: A bit of debugging reveals that sshd_t runs /usr/sbin/mkhomedir_helper on behalf of pam. But somehow the command ends up running in the userdomain.
To troubleshoot we tried to label /usr/sbin/mkhomedir_helper oddjob_mkhomedir_exec_t since sshd_t is allowed to run files with that type with a domain transition to oddjob_mkhomedir_t. However, although we figured out that sshd_t actually "executes" the file with that type it does not appear to be domain transitioning for some reason. The user home dir still gets created by /usr/sbin/mkhomedir_helper on behalf of root, running in the unconfined_t domain
Petr, did we add privsep patch also to F17?
Yes this looks like a setexeccon is overriding the oddjob execution.
I don't think it's related to the privsep patch. The privsep patch changes context of actual process with setcon() based on getexeccon() value. But there's the pam_selinux module which sets a user context for next execve call.
those two files works for me (together with the mkhomedir_helper context change): /etc/pam.d/sshd #%PAM-1.0 ... # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so session optional pam_keyinit.so force revoke session include password-auth # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session include postlogin /etc/pam.d/password-auth: #%PAM-1.0 ... session optional pam_keyinit.so revoke session required pam_limits.so session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
I added labeling.
selinux-policy-3.10.0-156.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-156.fc17
Package selinux-policy-3.10.0-156.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-156.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16347/selinux-policy-3.10.0-156.fc17 then log in and leave karma (feedback).
selinux-policy-3.10.0-156.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Having the exact same problem on RH el6.3 with selinux-policy-3.7.19-155.el6_3.13.noarch
Did you try to fix labeling using chcon?