Bug 115399

sshd:
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    required     pam_limits.so
session    optional     pam_console.so debug

system-auth:
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_ldap.so
session     optional      /lib/security/$ISA/pam_unix.so

/etc/ldap.conf:
host 144.91.XXX.XXX
base dc=mills,dc=edu
rootbinddn cn=ldaprootuser,dc=mills,dc=edu
timelimit 30
bind_timelimit 30
pam_min_uid 200
nss_base_passwd ou=People,dc=mills,dc=edu?one
nss_base_shadow ou=People,dc=mills,dc=edu?one
nss_base_group          ou=Group,dc=mills,dc=edu?one
nss_base_hosts          ou=Hosts,dc=mills,dc=edu?one
ssl no
pam_password md5

slapd.conf:
access to dn="" by * read
access to *
        by self read
        by users read
        by anonymous auth
database        ldbm
suffix          "dc=mills,dc=edu"
rootdn          "cn=ldaprootuser,dc=mills,dc=edu"
rootpw          MY-PRESIOUS
directory       /var/lib/ldap
index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
index   cn,mail,surname,givenname                       eq,subinitial

By setting up the proxyuser with read access ssh now works and root
can su to other users but a regular user can not su to root. No
segfault and  /var/log/messages reports a session opened and then
closed for root by user. I have never seen in the redhat documents the
need to set up the proxyuser, only only found this in mandrakes docs. 

/etc/ldap.conf
binddn cn=proxyuser,dc=mills,dc=edu
bindpw bigsupersecret

/etc/openldap/slapd.conf
access to dn="" by * read
access to *
        by dn="cn=proxyuser,dc=mills,dc=edu" read
        by self read
        by users read
        by anonymous auth

On my RHEL 3 server I was also experiencing a segmentation fault when
trying to su to root when using ldap.  I worked around this problem by
adding a pam_ldap.so entry to line #1 in /etc/pam.d/su service file as
shown below:

#%PAM-1.0
auth       sufficient   /lib/security/$ISA/pam_ldap.so use_first_pass
auth       sufficient   /lib/security/$ISA/pam_rootok.so
auth       required     /lib/security/$ISA/pam_stack.so
service=system-auth
account    required     /lib/security/$ISA/pam_stack.so
service=system-auth
password   required     /lib/security/$ISA/pam_stack.so
service=system-auth
session    required     /lib/security/$ISA/pam_stack.so
service=system-auth
session    optional     /lib/security/$ISA/pam_xauth.so

I have to confirm that su from any user  account (ldap, or passwd) to 
a ldap user account causes a segfault as well because I was able to 
reproduce the same problem. Never had to modify sshd_config for LDAP 
accounts to be able to login through SSH though.

Created attachment 102034 [details]
strace capture for su segmentation fault for ldap user

After examining the strace log and finding the line that read waitpid
(-1, su: cannot set groups: Operation not permitted, it directed me 
to thinking about my AD SFU unix groups. The primary group for my 
LDAP users that I was attempting to su to contained a space, after 
removing the space there was no more segfault using su. 

I dont know if this is the same issue the other guy is having here 

I'm not sure whether this could be considered a bug in su, but spaces 
in group names in the LDAP directory didn't seem to cause problems 
anywhere else.

Just adding my name to the list in case there's updates - I obviously
am having the same problem.

I had the "su - root" segfault problem here (RHES 3.1 with all 
updates on i386). It had been working fine then began to fail a 
couple of weeks ago. Travis Bean's fix, above, made it work again. 
However, I discovered this morning that we had two nscd processes 
running, only one of which could be stopped via the init.d script. I 
killed the "rogue" nscd process, restarted nscd, and the "su - root" 
problem was gone even after I removed Travis Bean's work around from 
PAM. 

I discovered that nscd is the problem.  If I run /usr/sbin/authconfig
and choose "Cache Information" (which invokes the nscd process), my
above mentioned workaround for /etc/pam.d/su is needed to prevent a
segmentation fault.  If nscd is never invoked by authconfig then the
/etc/pam.d/su default service file works fine.  

Sorry all for not updating our situation in a while but this was only
a problem for our first couple of systems we built up on RHEL 3. I
would say sense this summer su has worked fine. I did discover that
the original box that had this problem had this line in /etc/pam.d/su

auth       sufficient   /lib/security/$ISA/pam_ldap.so use_first_pass
Removing this line fixed all su issues

I also modify in system-auth
account     [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore] /lib/s
        ecurity/$ISA/pam_ldap.so

to

account     [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore authinfo_unavail=ignore] /lib/s
        ecurity/$ISA/pam_ldap.so

As it seems to help root login faster when the systems are offline,
root is a local account of course

I think maybe the original authconfig script had some issues that RH
fixed earlier this year.
Note: I do not cache login info but rather run several servers if they
are all down so is DNS so what does auth matter at that point.

I'm closing this bug as it seems to be OK for the original reporter now.
People who are cced on this, please open new bugs if you still see any
problems with updated RHEL installs.