When running 'su - username', pam_group doesn't add additional groups from /etc/security/group.conf but sshd login does?

Question

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/su and /etc/pam.d/sshd, but they both include identical files where pam_group.so is called (including system-auth and password-auth respectively, but those two included files are identical).

The relevant section of /etc/pam.d/su:

#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            include         system-auth

The relevant section of /etc/pam.d/sshd:

#%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:

*;*;*;Al0000-2400;apache,devs,rvm

When running 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 /etc/security/group.conf.

[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!

edit:

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.

Answer 1

I assumed your problem is the su-pam file and the pam_rootok module.

#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            include         system-auth

The sufficient clause short-cuts the authentication process. So system-auth never gets included, which means the pam_group module is never activated for this session.

Then, sigh I read your edit. Anyway, it definitely is a start to figuring this out. Maybe turn on debugging for pam_group to see if it returns one of the documented error values (man pam_group).

About sudo, it actually makes sense that after authenticating the user via PAM, all account information is thrown out/disabled. It has its own mechanisms for adding users to groups. Try adding the preserve_groups option for the relevant sudo entry.

All this makes me wonder: Why did pam make the group module only relevant to auth. It should, in fact, be part of account.

Answer 2

The auth lines are only looked at when processing a password, so are ignored for su when you're root, or for ssh using a public key.

I haven't found a way to make this work.