From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: Setup a Redhat machine with ldap. Necessary for create the home directory ist that with su - USERNAME the home directory automaticly will be create. For this i make a entry in the /PAM/SU. This don't work. When i test the same with login or other PAM modules it work When I remember with RH 7.2 or 7.3 it works. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create the entry in the pam su file pam/su gemacht. ###################################################################### #%PAM-1.0 auth sufficient /lib/security/pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient /lib/security/pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required /lib/security/pam_wheel.so use_uid auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_xauth.so 2.su - USERNAME (availible in the LDAP database) 3.su - hans Creating directory '/home/hans'. could not open session Actual Results: The home directory isn't created Expected Results: nothing, not possible to work with auto create LDAP accounts. Impossible for my client. Additional info: create entry in syslog.conf *.debug /var/log/debug ########################################### Nov 13 18:19:14 groupware slapd[1017]: conn=49 op=5 SRCH base="dc=creativix,dc=n etz" scope=2 filter="(&(objectClass=posixGroup)(|(memberUid=hans)(uniqueMember=c n=hans,ou=People,dc=creativix,dc=netz)))" Nov 13 18:19:14 groupware slapd[1017]: conn=49 op=5 SEARCH RESULT tag=101 err=0 text= Nov 13 18:19:14 groupware slapd[626]: conn=49 op=6 SRCH base="dc=creativix,dc=ne tz" scope=2 filter="(&(objectClass=posixAccount)(uid=hans))" Nov 13 18:19:14 groupware slapd[626]: conn=49 op=6 SEARCH RESULT tag=101 err=0 t ext= Nov 13 18:19:14 groupware PAM-mkhomedir[1433]: unable to create directory /etc/s kel Nov 13 18:19:14 groupware slapd[1000]: conn=49 op=7 SRCH base="dc=creativix,dc=n etz" scope=2 filter="(&(objectClass=posixAccount)(uid=hans))" Nov 13 18:19:14 groupware su(pam_unix)[1433]: session opened for user hans by ro ot(uid=0) Nov 13 18:19:14 groupware slapd[1000]: conn=49 op=7 SEARCH RESULT tag=101 err=0 text= Nov 13 18:19:14 groupware slapd[616]: conn=-1 fd=32 closed Nov 13 18:19:14 groupware slapd[1000]: conn=-1 fd=31 closed
Created attachment 103910 [details] Patch This patch temporarily sets fsuid to 0 so the pam_mkhomedir can create the user's home directory.
The patch above solves it on the pam side, but it's debatable if it wasn't better to move the setfsuid call in su after the pam_open_session call. Ccing twaugh as he is owner of coreutils.
Created attachment 106763 [details] New and better patch
Oh, workaround for this is "chmod 1777 /home", but you may not regard that as secure or desierable. I sent my patch upstream as well. The problem bites plenty hard because the session fails if the PAM fails. Nicolai
Comment on attachment 106763 [details] New and better patch I'm sorry but this patch is bogus.
I think this should be changed in su not in pam. The setfsuid and setfsgid calls should not be made before pam_open_session.
Is this still an issue?
Yes, it is.
What exactly are the requirements here? I can't see anything in the pam_open/close_session man page to suggest that setfsuid/gid() should be needed *after* pam_open_session, only before: pam_open_session [...] Some types of functions associated with session initialization are logging for the purposes of system-audit and mounting directories (the userâs home directory for example). These should not concern the application. It should be noted that the effective uid, geteuid(2), of the application should be of suf- ficient privilege to perform such tasks.
After looking at the history of the pam patch, and the reason that the setfsuid/gid() calls were added in the first place, I think they can now be removed. Does 5.2.1-34 fix this bug?