|
Bugzilla – Full Text Bug Listing |
| Summary: | Sudoers only finds Primary Group (AD, SSSD) | ||
|---|---|---|---|
| Product: | Sudo | Reporter: | Clayton D <clayton.daley+sudo> |
| Component: | Sudoers | Assignee: | Todd C. Miller <Todd.Miller> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | ||
| Priority: | low | ||
| Version: | 1.8.20 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Attachments: | Full (Sanitized) Debug Log | ||
|
Description
Clayton D
2017-06-21 10:43:54 MDT
When sudo looks up a user's groups, it either uses the getgroups() system call or uses the getgrouplist() function. By default, sudo will use getgroups() as long as the number of groups is less than the max for NFS. In that case it uses getgrouplist(). You can control this via the group_source setting in sudo.conf. In your debug log is there a line like: groups=... That info is logged by plugin@info and should show you the list of the user's groups as sudo sees them. Also, is you run the "groups" command as that user, does it list linuxadmins as one of the groups? I assume this is the group line to which you refer: Jul 2 22:45:34 sudo[43850] <- get_user_groups @ ./sudo.c:492 := groups=1157000512,1157000513,1157000519,1157000572,1157001118,1157001133,1157001137,1157001145,1157001146,1157001152,1157001153,1157001166 And "groups" does show the right group (domain sanitized): domain users@domain.com domain admins@domain.com enterprise admins@domain.com denied rodc password replication group@domain.com dnsadmins@domain.com linuxadmins@domain.com deployers@domain.com graylog@domain.com graylogadmins@domain.com testing@domain.com workflow@domain.com linuxusers@domain.com However, in the LDAP rules section, I'm still seeing getgrgid only run on one (primary) group: Jul 2 22:45:34 sudo[43850] sudo_get_grlist: looking up group names for user@domain.com ... Jul 2 22:45:34 sudo[43850] sudo_getgrgid: gid 1157000513 [] -> group domain users@domain.com [] (cache hit) It looks like sudo is getting the correct group IDs so I don't know why you'd only see a single call to sudo_getgrgid(). Do you see any lines in the debug log like: sudo_get_grlist: user user@domain.com is a member of group ... It's hard to tell what is going on from small snippets of the debug log. You might try setting the match_group_by_gid option which changes how groups get matched. If the problem is ID -> name group resolution this may help. Created attachment 495 [details]
Full (Sanitized) Debug Log
FWIW here's a full debug log. I tried to capture just `sudo -v` for the focal user. In some places, you can see the whole list enumerated (interesting as <group>@domain.com). Does the rule need to include the @domain.com section? In the `sudoers` file it does not so I assumed that this code would follow the same conventions.
The debug log shows that group ID 1157001133 resolves to group name linuxadmins@domain.com so I think you do need to include the @domain part in the rule. The lines tagged with "sudo_get_grlist:" show all the names of the groups tthat he user is a member of. OK. I tried changing the entry in LDAP to `%linuxadmins@domain.com` but the rule doesn't even load: Jul 5 11:40:58 sudo[42228] Received 1 rule(s) ... Jul 5 11:40:58 sudo[42228] val[0]=%deployers This is the second (unchanged) rule. I couldn't find anything about escaping so I tried `\@` which didn't help. Do I need to follow up with the sssd folks to clarify escaping for this character? FWIW if this approach ultimately requires `@domain`, it will differ from the current `/etc/sudoers` behavior. |