Bug 77791 - pam_mkhomedir cannot create home when called from su
pam_mkhomedir cannot create home when called from su
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-13 12:35 EST by Reiner Jung
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 5.2.1-34
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-06 10:51:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch (3.62 KB, patch)
2004-09-16 11:09 EDT, Tomas Mraz
no flags Details | Diff
New and better patch (2.37 KB, patch)
2004-11-15 17:56 EST, Nicolai Langfeldt
no flags Details | Diff

  None (edit)
Description Reiner Jung 2002-11-13 12:35:42 EST
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
Comment 1 Tomas Mraz 2004-09-16 11:09:57 EDT
Created attachment 103910 [details]
Patch

This patch temporarily sets fsuid to 0 so the pam_mkhomedir can create the
user's home directory.
Comment 2 Tomas Mraz 2004-09-16 11:13:29 EDT
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.
Comment 3 Nicolai Langfeldt 2004-11-15 17:56:27 EST
Created attachment 106763 [details]
New and better patch
Comment 4 Nicolai Langfeldt 2004-11-15 17:58:26 EST
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 5 Tomas Mraz 2004-11-16 10:20:47 EST
Comment on attachment 106763 [details]
New and better patch

I'm sorry but this patch is bogus.
Comment 6 Tomas Mraz 2004-11-16 11:10:08 EST
I think this should be changed in su not in pam. The setfsuid and
setfsgid calls should not be made before pam_open_session.
Comment 7 Tim Waugh 2004-12-06 07:17:12 EST
Is this still an issue?
Comment 8 Tomas Mraz 2004-12-06 07:28:31 EST
Yes, it is.
Comment 9 Tim Waugh 2004-12-06 08:30:05 EST
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.
Comment 10 Tim Waugh 2004-12-06 10:51:52 EST
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?

Note You need to log in before you can comment on or make changes to this bug.