I am having trouble determining why
su doesn't behave as the PAM configuration would imply. In short, using
su to become another user should load secondary groups according to PAM configuration, but
pam_group isn't adding the
/etc/security/group.conf groups, we only end up with our LDAP groups. When logging in via SSH as a user, you have groups from both sources.
Our setup is not too far from default CentOS 6.5, we're using SSSD to provide logins via Kerberos / LDAP but have not made direct changes to anything in
/etc/pam.d as far as I recall, the changes were made by :
authconfig --updateall --enablesssd --enablesssdauth --enablemkhomedir
There are of course separate
/etc/pam.d/sshd, but they both include identical files where
pam_group.so is called (including
password-auth respectively, but those two included files are identical).
The relevant section of
#%PAM-1.0 auth sufficient pam_rootok.so auth include system-auth
The relevant section of
#%PAM-1.0 auth required pam_sepermit.so auth include password-auth
In the included file:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth optional pam_group.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so ...
When logging in via SSH, the pam_group.so line adds groups via
/etc/security/group.conf, adding 'apache' group (among others) to anyone who logs in:
su - username as root (or
sudo su - ... as anyone else), and becoming another user, this pam_group does not appear to add these additional groups. In fact, where logging in as root gives you these groups (because pam_group did it's job), running
su - username results in you losing those groups, because
su starts from nothing and only adds in the groups it gets from PAM (LDAP groups essentially, since pam_group isn't working)
Here you can see, logged in as root initially, I have apache (48), devs (501), and rvm (504), but running just
su - to login as root I lose everything but root (0). Further, logging in as user 'bob' using
su - bob you can see I have a lot of groups from LDAP (plus one hardcoded group from /etc/group that does work), but nothing from
[root@dev-web pam.d]# id -G 0 48 501 504 [root@dev-web pam.d]# su - [root@dev-web ~]# id -G 0 [root@dev-web ~]# logout [root@dev-web pam.d]# su - bob [bob@dev-web ~]$ id -G 1005001 10 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
Finally, what a SSH login as bob looks like - again I have apache (48), devs (501), and rvm (504).
[bob@dev-web ~]$ id -G 1005001 10 48 501 504 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
One might assume the difference between
su - username and logging in with SSH is that in the SSH case there is a password available for the various modules that use
try_first_pass and so on, but since we often are logging in using Kerberos there's no password for these modules.
I'll provide any further information (within reason) if it will help diagnose this discrepancy. Thanks in advance!
I have turned on PAM debugging and
pam_group doesn't appear to fire for
su - even if I disable
pam_rootok so I have to log in (to make sure it actually tried to go through the rest of the pam stack). Regardless of where it is in the stack, other items fire (once
pam_rootok is disabled, since it's "sufficient" status seems to short circuit the stack).
Also it only occurred to me to test
sudo, and it seems to have nearly the same problem. Root can
sudo to itself and keep groups, but
sudoing to another user only gets LDAP groups.
/etc/pam.d/sudo just includes
/etc/pam.d/system-auth which is the same stack
su uses, so that shouldn't be a surprise. I suppose
sudo is smart enough to not actually drop permissions / switch user if the target user is the same as current user, hence root keeping groups.