Bug 694

Summary:	Netgroup ldap search seems incorrect on 1.8.13
Product:	Sudo	Reporter:	sudo
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	low
Version:	1.8.13
Hardware:	PC
OS:	Linux

Description sudo 2015-04-07 18:50:12 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

Comment 1 Todd C. Miller 2015-04-08 11:23:55 MDT

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?

Comment 2 sudo 2015-04-08 12:40:55 MDT

getent initgroups systems
Unknown database: initgroups

getent group systems
systems:*:10001:systems

getent group support3
support3:*:20009:systems,tech1

Comment 3 Todd C. Miller 2015-04-08 13:36:02 MDT

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

Comment 4 sudo 2015-04-08 14:07:18 MDT

Apr  8 16:02:05 sudo[30628] <- get_user_groups @ ./sudo.c:440 := groups=10001

Comment 5 Todd C. Miller 2015-04-08 14:13:03 MDT

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

Comment 6 Todd C. Miller 2015-04-08 14:29:08 MDT

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).

Comment 7 Todd C. Miller 2015-07-17 09:29:36 MDT

Does not appear to be a sudo problem.