Bugzilla – Bug 694
Netgroup ldap search seems incorrect on 1.8.13
Last modified: 2015-07-17 09:29:36 MDT
The object is to grant sudo access to user 'systems' on host 'hostname01' 1. This setup is working fine with sudo-1.7.2p1 on Centos5 2. Sudo 1.8.13 isn't searching for nisNetgroupTriple=(hostname01,,) which is a valid netgroup 3. Sudo 1.8.13 doesn't appear to be searching for this user's groups In LDAP, 'systems' user is in the 'support3' group and 'support3' group can run as root on all hosts in 'cpe' netgroup, and 'hostname01' is a member of 'cpe' netgroup. My ldap schema is as follows: cn=support3,ou=groups,ou=support,dc=testsudo,dc=net memberUid = systems cn=cpe,ou=netgroup,dc=testsudo,dc=net nisNetgroupTriple = (hostname01,,) cn=support3,ou=sudoers,dc=testsudo,dc=net sudoHost = +cpe sudoRunAs = root sudoUser = %support3 For sudo-1.7.2p1-9.el5_5 on Centos5: sudo: ldap search '(|(sudoUser=systems)(sudoUser=%systems)(sudoUser=%eng3)(sudoUser=%neteng3)(sudoUser=%support3)(sudoUser=ALL))' sudo: found:cn=support3,ou=sudoers,dc=testsudo,dc=net sudo: ldap sudoHost '+cpe' ... MATCH! sudo: ldap sudoRunAsUser 'root' ... MATCH! sudo: ldap sudoCommand 'ALL' ... MATCH! sudo: Command allowed sudo: user_matches=1 sudo: host_matches=1 For sudo-1.8.13-1.el6.x86_64 on Centos6.6: sudo: searching from netgroup_base 'ou=netgroup,dc=testsudo,dc=net' sudo: ldap netgroup search filter: '(&(objectClass=nisNetgroup)(|(nisNetgroupTriple=\(,systems,*\))(nisNetgroupTriple=\(hostname01,systems,*\))))' sudo: ldap search '(&(objectClass=sudoRole)(|(sudoUser=systems)(sudoUser=%systems)(sudoUser=%#10001)(sudoUser=ALL)))' sudo: searching from base 'ou=sudoers,dc=testsudo,dc=net' sudo: adding search result sudo: result now has 0 entries sudo: sorting remaining 0 entries sudo: searching LDAP for sudoers entries sudo: done with LDAP searches sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x40 Now if I add nisNetgroupTriple = (hostname01,systems,) to the netgroups, then I get this: sudo: Looking up netgroups for systems sudo: searching from netgroup_base 'ou=netgroup,dc=testsudo,dc=net' sudo: ldap netgroup search filter: '(&(objectClass=nisNetgroup)(|(nisNetgroupTriple=\(,systems,*\))(nisNetgroupTriple=\(hostname01,systems,*\))))' sudo: Found new netgroup cpe for ou=netgroup,dc=testsudo,dc=net sudo: Checking for nested netgroups from netgroup_base 'ou=netgroup,dc=testsudo,dc=net' sudo: ldap netgroup search filter: '(&(objectClass=nisNetgroup)(|(memberNisNetgroup=cpe)))' sudo: ldap search '(&(objectClass=sudoRole)(|(sudoUser=systems)(sudoUser=%systems)(sudoUser=%#10001)(sudoUser=+cpe)(sudoUser=ALL)))' sudo: searching from base 'ou=sudoers,dc=testsudo,dc=net' sudo: adding search result sudo: result now has 0 entries sudo: sorting remaining 0 entries sudo: searching LDAP for sudoers entries sudo: done with LDAP searches sudo: user_matches=1 sudo: host_matches=0
I think the netgroup stuff is a red herring. The problem appears to be that the LDAP search does not include the support3 group. Group handling has changed significantly in sudo. Can you show me the output of: getent initgroups systems and getent group systems on the Centos6.6 machine?
getent initgroups systems Unknown database: initgroups getent group systems systems:*:10001:systems getent group support3 support3:*:20009:systems,tech1
Looks like "getent initgroups" is not supported in CentOS 6 even though it is documented (works in CentOS 7). Please try running sudo with the following in /etc/sudo.conf (which you will probably have to create) Debug sudo /var/log/sudo_debug util@debug This will write debug info to /var/log/sudo_debug. We're specifically interested in a line like: Apr 8 15:31:21 sudo[1857] <- get_user_groups @ ./sudo.c:429 := groups=10001, 20009
Apr 8 16:02:05 sudo[30628] <- get_user_groups @ ./sudo.c:440 := groups=10001
This shows that the group vector for user systems only contains the systems group and not the support3 group. This is set when the user logs in. It's possible your nsswitch.conf is not setup to query the correct group databases or, if using the /etc/group file, you are testing a session that was logged in before support3 was added to /etc/group. Depending on what the underlying problem actually you might be able to work around it with a line like the following in /etc/sudo.conf Set group_source dynamic
BTW, you can verify that there is a problem with the groups for user systems by creating a file owned by a different user (say root) and readable only by owner and group support3 (say mode 640). If systems cannot read the file then you know that group support3 is not in its group vector (set at login time).
Does not appear to be a sudo problem.