Description of problem: Version-Release number of selected component (if applicable): selinux-policy-targeted-3.5.13-34.fc10.noarch gdm-2.24.1-2.fc10.i386 authconfig-gtk-5.4.4-1.fc10.i386 How reproducible: 100% Steps to Reproduce: 1.in system-config-authentication, go to Options tab, check "Create home directories on first login" checkbox, hit OK 2.add a user whose home dir does not exist (in my case, the user is from NIS, with home dir in /home/username) 3.use gdm login screen to log in as that user Actual results: An error dialog about "/home/something/.ICEsomething". Dismiss that and it just sits forever with a busy cursor and a default background, never logs in or errors out. Expected results: Log me in, create the home dir. Additional info: setroubleshoot complains and says I have to fix it by running setsebool -P polyinstantiate_something. Doing what it says does not make it work. 'echo 0 > /selinux/enforce' makes it work just fine (but it leaves the new homedir improperly labelled, I think). No setsebool magic should be required. If something like that is needed, system-config-authentication should do it.
I believe the problem here is the adding of pam_mkhomedir instead of using pam_oddjob_mkhomedir. pam_mkhomedir forces us to add a lot of heavy privs to login programs, like the ability to totally control user content. I would like to prevent this since allowing it would allow compromized apps like gdm and sshd to manipulate the homedir without the attacker having to login.
*** Bug 476674 has been marked as a duplicate of this bug. ***
I'm currently changing pam_mkhomedir module to call a helper. I do not like using the oddjob_mkhomedir.
The pam-1.0.90-2.fc11 in tomorrows rawhide contains the modified pam_mkhomedir which calls the helper. Now the selinux policy has to be modified accordingly - that is add a new domain for the /sbin/mkhomedir_helper and add auto transition from the confined login contexts to this domain and allow this domain creation of the home directories and copying contents of skel to them.
If you label it oddjob_mkhomedir_exec_t does it work?
Yes, it works. Actually it partially works even if I do not relabel the mkhomedir_helper but I put the module after 'pam_selinux.so open'. But in that case the home directory and it's contents which was copied from skel get home_root_t labels. And this wrong labelling happens regardless of the label on the /sbin/mkhomedir_helper. This should be solved in the policy somehow, because the system-auth where authconfig places the pam_mkhomedir is included now after the pam_selinux open call.
Well that is a problem. The only reason this works at all is that you are logging in as unconfined_t and this is allowed to create the homedir, If you used a confined user this would fail. The policy to create the home dir is contained in oddjob_mkhomedir_exec_t, and this executable has the knowledge to label the directory correctly. Your helper needs to be calling matchpathcon for each file in /etc/skel to make sure it creates everything correctly. I would suggest we combine your helper app ahd oddjob_mkhomedir together. Any executable that is executed after the pam_selinux_open is going to be run in the users context. The correct way to do this might be to move to a dbus system service where the login programs send a dbus message which causes the labeling to happen.
I'd still like to avoid dbus dependency on the base pam package. As the change to move the system-auth after pam_selinux open is just in rawhide I might probably back it out. If this is necessary for some other module we could even split the session part of system auth to another file which would contain the modules which need to run with the final user context.
Well pam_mkhomedir should probably not be in the base package... We have better ways to do this, then trying to hack around with pam base.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to comment #11) > Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is > no longer maintained, which means that it will not receive any further > security or bug fix updates. As a result we are closing this bug. > > If you can reproduce this bug against a currently maintained version of > Fedora please feel free to reopen this bug against that version. > > Thank you for reporting this bug and we are sorry it could not be fixed. This is still an issue for me in fedora 12. Could someone please look into it? I know next to nothing about selinux.
Yes can you use pam_oddjob_mkhomedir instead This will work with SELinux.
(In reply to comment #13) > Yes can you use pam_oddjob_mkhomedir instead > > This will work with SELinux. I have no idea what that is or how to use it instead.
http://people.redhat.com/nalin/oddjob/README.html # yum install oddjob\* # man pam_oddjob_mkhomedir This will tell you how to set it up.
Well, I looked into that(both man page and website) and it looked, at least to me, like all the configuration was set up properly. I added session optional /lib/security/pam_oddjob_mkhomedir.so(from the man page) to /etc/pam.d/system-auth-ac and commented out session optional pam_mkhomedir.so. I then did chkconfig oddjobd on and service start oddjobd. The problem from the bug is still happening. I'm sure i'm missing something, but could you help me with what it is?
Are you getting avc messages? You removed pam_mkhomedir?
(In reply to comment #17) > Are you getting avc messages? You removed pam_mkhomedir? Well, I don't see a way to remove pam_mkhomedir, at least not with yum. As far as the avc messages, i have many repeating messages of the following: type=AVC msg=audit(1267048768.008:166): avc: denied { write } for pid=6254 comm="xauth" name="cc0164937" dev=dm-0 ino=657401 context=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dir Using ls -Z i see that after the directory is made it lists: unconfined_u:object_r:home_root_t:s0 The other home directories are: unconfined_u:object_r:user_home_dir_t:s0 After i do restorecon -R /home/<username> it is: unconfined_u:object_r:user_home_dir_t:s0 Just like the others.
I apologize for the double comment, but I forgot to add that after the restorecon command i can successfully log in.
Chris remove pam_mkhomedir from the /etc/pam.d/* files.
Okay, that's what I was missing. I removed it from system-auth but didn't even look in the other files. After removing pam_mkhomdir from all files in /etc/pam.d/* , as well as adding oddjob to them all, it works! Any chance this could become automatic/more well documented? Thanks!
The "solution" of "use this nonstandard plug-in and fiddle config files by hand" is not an acceptable solution. There is a check-box in the admin interface presented by the vanilla install, SELinux is enabled in the vanilla install, and they don't work together. That's just broken out of the box. Fortunately comment#3 indicates an intent to actually fix the bug. When that's done, this report can be closed. It's certainly fine with me if that fix doesn't hit until F-13 (or even F-14). Just indicate "fixed in version" and such accurately when you close this bug.
*** Bug 568839 has been marked as a duplicate of this bug. ***
The new authconfig in which is waiting for push to F13 testing uses pam_oddjob_mkhomedir if the appropriate package is installed. Someone still needs to add the oddjob-mkhomedir to comps to be installed by default though. In case the pam_oddjob_mkhomedir is not available authconfig will use pam_mkhomedir.
If it needs to be installed by default, then authconfig should just require it. It'll probably also need to manage an ACL file for the service: the 'mkmyhomedir' method is not allowed to unprivileged users by default, but since configuration files are merged, dropping one in that allows them to use it can save you the trouble of having to edit the file that comes with the package. <oddjobconfig> <service name="com.redhat.oddjob_mkhomedir"> <object name="/"> <interface name="com.redhat.oddjob_mkhomedir"> <method name="mkmyhomedir"> <allow min_uid="500"/> </method> </interface> </object> </service> </oddjobconfig>
No, authconfig will not require it. I want to keep the requires on authconfig on the bare minimum. As the pam_oddjob_mkhomedir is run as root uid, the ACL should not be needed or am I wrong?
(In reply to comment #27) > No, authconfig will not require it. I want to keep the requires on authconfig > on the bare minimum. As the pam_oddjob_mkhomedir is run as root uid, the ACL > should not be needed or am I wrong? When run as root, it requests a method ("mkhomedirfor") which root is authorized to use, yes. But I thought the original motivation was to handle the cases where the calling application had already dropped privileges to those of a non-root user, and for those cases an ACL entry needs to be added for that method ("mkmyhomedir").
Not for PAM. The only motivation here was to overcome the SELinux policy restrictions so the process that's creating the home directory does not run with the user context.
Can't authlogin request packages based on path if they are not installed. Seems silly to be installing all possible login methods by default. If a admin wants to setup user accounts to be autocreated, we should you yum to add the package if it is not installed.