Bug 104997 - pam_mkhomedir.so fails to autocreate home directories
pam_mkhomedir.so fails to autocreate home directories
Status: CLOSED DUPLICATE of bug 135572
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-24 10:28 EDT by Brian Baggett
Modified: 2007-11-30 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 04:44:05 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)

  None (edit)
Description Brian Baggett 2003-09-24 10:28:38 EDT
Description of problem:
I use LDAP to authenticate all users in my environment.  In previous versions of
PAM w/RH, I could have the following in my /etc/pam.d/system-auth:

ession     required      /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0
022
session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_ldap.so

But in Taroon Beta 2, the pam_mkhomedir line does not work.  It causes this
error in /var/log/secure:

Sep 24 04:58:48 elpcsm10 sshd[8931]: Accepted password for tperry from
10.130.28.231 port 4882 ssh2
Sep 24 04:58:49 elpcsm10 sshd[8933]: fatal: PAM session setup failed[6]:
Permission denied

Removing the pam_mkhomedir directive works.  The default permissions on /home
are 755.

Version-Release number of selected component (if applicable):

pam-0.75-51

How reproducible:

Every time.

Steps to Reproduce:
1.  Place the above entry for pam_mkhomedir.so in the /etc/pam.d/system-auth
2.  Try to login with an account that doesn't currently have a home dir.
3.  Profit!!
    
Actual results:

User can't login.  Error mesg thrown to log file is "fatal: PAM session setup
failed[6]: Permission denied"  No home directory autocreated either.

Expected results:

User should be able to login and a home directory should be created.

Additional info:
Comment 1 Matt Wilson 2003-09-25 19:18:22 EDT
is this with all services or just one?  Does local login work?  telnet?  ssh? 
May be the app has dropped privs required to make the homedir before that part
of the stack is run
Comment 2 Brian Baggett 2003-09-26 13:06:51 EDT
SSH and FTP drop privs (apparently).  Telnetting in will create a home
directory.  So where do we go from here?  Is it a problem in PAM or in SSH and FTP?

[root@elpcsm10 home]# telnet localhost
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Red Hat Enterprise Linux release 2.9.5AS (Taroon)
Kernel 2.4.21-3.EL on an i686
login: brianb
Password: 
Creating directory '/home/brianb'.
Last login: Fri Sep 26 07:48:41 from localhost.localdomain
[brianb@elpcsm10 brianb]$


[root@elpcsm10 home]# service vsftpd restart
Shutting down vsftpd:                                      [FAILED]
Starting vsftpd for vsftpd:                                [  OK  ]
[root@elpcsm10 home]# ftp localhost
Connected to localhost.localdomain.
220 (vsFTPd 1.2.0)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (localhost:root): brianb
331 Please specify the password.
Password:
500 OOPS: cannot change directory:/home/brianb
Login failed.
421 Service not available, remote server has closed connection
ftp> quit
Comment 3 Mark H Johnson 2003-10-14 11:03:36 EDT
I am having the same problem with Fedora Test 2. For example...

ssh dws77
u21305@dws77's password:
Creating directory '/home/u21305'.
Could not chdir to home directory /home/u21305: No such file or directory
/usr/X11R6/bin/xauth:  error in locking authority file /home/u21305/.Xauthority

An ugly work around is to
  chmod 777 /home
which produces the following result:

ssh dws77
u21305@dws77's password:
Creating directory '/home/u21305'.
/usr/X11R6/bin/xauth:  creating new authority file /home/u21305/.Xauthority

which is the right behavior, but with an obvious security problem. From a quick
look at mailing lists such as
  https://listman.redhat.com/archives/pam-list/2003-July/msg00007.html
it appears there may be a bug in the sequence leading to the directory creation.
Comment 4 Matthieu Heimer 2004-05-11 12:10:46 EDT
The work around for now is to edit sshd_config and set
UsePrivilegeSeparation no

After that add
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0022
to /etc/pam.d/login and /etc/pam.d/sshd

You shouldn't add anything manualy to /etc/pam.d/system-auth since
running authconfig will kill your changes. And setting /home to 777 is
just a little unsecure.

I'm testing this on Fedora Core 1 and now everything works great so
far. Apparently this will/is be fixed in ssh 3.8p1-1 or atleast that's
what this
thread(http://lists.debian.org/debian-ssh/2004/03/msg00032.html) lead
me to believe.
Comment 5 Brian Baggett 2004-06-03 09:26:02 EDT
Good call on the privilege seperation thing.  That's the ticket!

Incidentally, I always edit 'system-auth' because every other service
uses it so it's a good one-stop file to edit.  Either I edit every
service in pam.d and add the mkhomedir line or edit system-auth once
and I'm done.  Which makes more sense? :-)

I had bad experiences with authconfig in RHEL 2.1, so that's a moot
point for me.  Well that and I already have a system-auth file that
works for me.
Comment 6 Eric Paris 2004-09-03 08:59:25 EDT
Allthough priviledge seperation is a possible workaround for users
accessing the machine using ssh, it is by no means a fix.  Other
methods of login, such as su or ftp, both change the uid to the user
and make the mkdir "/home/<user>" call with the user uid.  I say this
is a bug because other session modules such as pam_limits must be
running with root permissions since it can set higher limits than
default even with priviledge seperation on.  If pam_limits is running
with root permissions why shouldn't pam_mkhomedir be dong the same. 
Priviledge seperation is a temporary workaround for users accessing
the machine with ssh, but is not the fix. 
Comment 7 Nathan Yehle 2004-09-20 17:17:46 EDT
Hi All, 
I have been using samba, with an openldap back end storing the
SID->UID/GID mappings from a windows 2003 active directory server.  We
use the pam_mkhomedir.so module, allowing local access through gdm and
remote through ssh.  I am using the "privledge seperation no" setting,
to allow sshd to create a homedirectory.  Sometimes however, I Get
calls from users who tried using ssh or gdm, saying they cannot login,
and when I check their homedirectory has been created but owned either
by another user, or a UID that doesn't exist in the system.  Has
anyone else seen this bug?  Once I chown the homedirectory to the
correct UID it works fine, but still this is very annoying, and it
doesn't happen every time so I am at a loss as to what is causing
it...  My openldap backend has the correct mappings stored for them,
but somehow I think pam_mkhomedir.so is just picking random UIDs for
the directory it creates.
Comment 8 Tomas Mraz 2004-09-21 07:17:29 EDT
I don't see this problem and I have PrivilegeSeparation enabled in
sshd_config file.

I have latest devel packages pam-0.77-56 and openssh-3.9p1-4.
Comment 9 Tomas Mraz 2004-11-10 09:44:11 EST
Should we fix that somehow in RHEL-3? I'm afraid the problem lies in
how older openssh releases implemented priviledge separation. That's
the reason I don't see it on latest pam+openssh.
Comment 10 Tomas Mraz 2005-02-07 04:44:05 EST

*** This bug has been marked as a duplicate of 135572 ***

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