PAM, LDAP and pam_mkhomedir

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Thu Feb 19 19:36:24 UTC 2004


Nalin Dahyabhai wrote :

> On Wed, Feb 18, 2004 at 05:40:12PM +0100, Matthias Saou wrote:
> > I'm currently trying to have an FC2 test1 workstation authenticate against a
> > central LDAP database. I currently only have RHL 7.3 machines doing something
> > similar, so maybe these are changes/issues already present in FC1.
> > 
> > - When I add the line below to /etc/pam.d/system-auth, the user's home
> >   directory only gets created if the user has write access to the directory in
> >   which his home directory will reside. Say I have /home/location/user,
> >   the "user" directory is created only if /home/location already does too
> >   and if there is write access to /home/location for the "user" user.
> >   Is this a feature or security enhancement? It renders the module basically
> >   useless for me...
> > 
> > session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=076
> 
> SSHD is performing session setup as the user, not as root.  This gets
> flipflopped every now and again to try to make pam_limits work (which
> can't be fixed 100% within the framework PAM provides, sigh).

That figures. I guess I'm stuck wrt sshd and pam_mkhomedir then, and this
also explains why my last attempts at making pam_limits works were equally
unsuccessful.

> > - When an LDAP authenticated user logs in through ssh, it's impossible for him
> >   to do any uid/gid <-> name mapping. For instance, if I change the owner of a
> >   file to be a user in the LDAP database, doing "ls -l" on it as root does
> >   generate connections to the LDAP database and shows the user's name, whereas
> >   when logged in as the user, there is no LDAP activity and it shows the
> >   numeric uid.
> > 
> > Maybe related to this 2nd issue, here is what an LDAP user gets through ssh :
> > 
> > $ ssh user at computer
> > user at computer's password:
> > Creating directory '/home/location/user'.
> > /usr/X11R6/bin/xauth:  creating new authority file /home/location/user/.Xauthority
> > id: cannot find name for user ID 501
> > id: cannot find name for group ID 1000
> > id: cannot find name for user ID 501
> > [I have no name!@computer user]$
> > 
> > Where uid 501 is the user's uid, and gid 1000 his primary group.
> 
> These two look very related.  I'd guess that one or more configuration
> files (/etc/ldap.conf, mainly) aren't readable by the user, so the
> user's processes don't "know" how to contact your LDAP server.
> Double-check the permissions, or try running "id" under strace and
> monitor for access control (EACCES) and related errors.

Certainly the issue. I think I misunderstood how nss worked, as I wouldn't
have thought users needed read access to the /etc/ldap.conf file. Thanks for
the info.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.6.2-1.81
Load : 0.30 0.20 0.17





More information about the fedora-test-list mailing list