Bug 946

Summary:	the form %group fails when the user belongs to too many groups
Product:	Sudo	Reporter:	galen.chen <anhuichen1992>
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bugzilla, rutvxlifhg
Priority:	low
Version:	1.9.3
Hardware:	Macintosh
OS:	MacOS X

Description galen.chen 2020-11-24 00:36:45 MST

If a user belongs to many groups, the form %group will fail for this user.

 For example, there is a user "testuser", it belongs to many groups:

testuser@test1s-Mac-2 ~ % id testuser 
uid=503(testuser) gid=20(staff) groups=20(staff),30021(testgroup21),30015(testgroup15),30005(testgroup5),30018(testgroup18),30013(testgroup13),30003(testgroup3),30019(testgroup19),30009(testgroup9),30001(testgroup1),30012(testgroup12),30014(testgroup14),30024(testgroup24),30002(testgroup2),30006(testgroup6),30022(testgroup22),12(everyone),61(localaccounts),30023(testgroup23),30008(testgroup8),30011(testgroup11),30025(testgroup25),30016(testgroup16),30020(testgroup20),30017(testgroup17),30010(testgroup10),30007(testgroup7),30004(testgroup4),704(com.apple.sharepoint.group.4),703(com.apple.sharepoint.group.3),701(com.apple.sharepoint.group.1),100(_lpoperator),702(com.apple.sharepoint.group.2)

 and there is an item of the form %group in /etc/sudoers:

test1s-Mac-2:~ root# cat /etc/sudoers
...
%testgroup21            ALL = (ALL) ALL
...

 The user should be able to execute sudo, but it fails:

testuser@test1s-Mac-2 ~ % sudo ls
Password:
testuser is not in the sudoers file.  This incident will be reported.

 Note: this is not a 100% reproduced issue, because some groups can work, some groups can not.

Comment 1 galen.chen 2020-11-24 01:54:04 MST

I know the reason:
In my situation, sudo uses the group_source() to lookup groups, but it does not get all groups.
After I set "Set group_source dynamic" in the /etc/sudo.conf, this issue disappeared.

Comment 2 Todd C. Miller 2020-12-03 16:07:36 MST

Looking at the source for id(1) in macOS I see that it does the same thing as setting "group_source" to "dynamic" in sudo.conf.  I'm a little surprised this is needed since macOS supports large group sets with getgroups(2).  I need to do some experimentation to see if I can reproduce the problem and whether there is a solution besides just changing the default value of "group_source" on macOS.

Comment 3 Todd C. Miller 2020-12-07 13:19:20 MST

This is fixed by the following commit:
https://www.sudo.ws/repos/sudo/rev/2e7d3c3cf18b

Comment 4 Todd C. Miller 2020-12-17 14:59:49 MST

Fixed in sudo 1.9.4p1

Comment 5 jon.king 2021-03-01 15:29:06 MST

I'm not sure that this has been fixed, or if there's another underlying issue on macOS.

I'm on 
Sudo version 1.9.5p2
Sudoers policy plugin version 1.9.5p2
Sudoers file grammar version 48
Sudoers I/O plugin version 1.9.5p2
Sudoers audit plugin version 1.9.5p2

I was occasionally, ~10% of sudo attempts, getting errors like
sudo: 4294967295: invalid value
sudo: error initializing audit plugin sudoers_audit

or just
<user> is not in the sudoers file.

I enabled debug logging with 
Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug

and saw what looks like inconsistent results from get_user_groups via getgroups().
A few attempts that succeeded:

Feb 26 17:12:33 sudo[17502] get_user_groups: got 15 groups via getgroups()
Feb 26 17:12:33 sudo[17502] <- get_user_groups @ /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/sudo/sudo-87.140.2/sudo/src/sudo.c:483 := groups=425392673,1073741824,0,1073741824,15,8,4,64,0,0,0,0,0,0,0
...
Feb 26 17:12:47 sudo[17718] get_user_groups: got 15 groups via getgroups()
Feb 26 17:12:47 sudo[17718] <- get_user_groups @ /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/sudo/sudo-87.140.2/sudo/src/sudo.c:483 := groups=425392673,3758096384,0,3758096384,2296381444,32649,200,0,1,0,2296404112,32649,0,0,0

And one that failed right after:
Feb 26 17:13:49 sudo[18142] get_user_groups: got 15 groups via getgroups()
Feb 26 17:13:49 sudo[18142] <- get_user_groups @ /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/sudo/sudo-87.140.2/sudo/src/sudo.c:483 := groups=425392673,1073741824,3063154287,3489662969,37,16,8,0,1765825792,32667,0,196608,2486072024,32767,4294967295
...
Feb 26 17:13:49 sudo[18142] 4294967295: invalid value @ sudo_parse_gids_v1() /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/sudo/sudo-87.140.2/sudo/lib/util/gidlist.c:76

My results from id:
uid=701980483 gid=425392673 groups=425392673,702,12,62,80,501,701,33,98,100,204,250,395,398,400

Setting "Set group_source dynamic" did fix this issue for me, so thanks for that.

Comment 6 MacTroy 2021-03-02 13:46:33 MST

I'm seeing similar results as jon.king — ever since the 11.2.1 macOS upgrade, sudo for our Admin,Mobile users (bound to OpenLDAP) is unpredictable. Any given sudo attempt has ~70% chance of resulting in "myldapuser is not in the sudoers file.  This incident will be reported.", ~10% chance of getting the "sudo: 4294967295(potentially additional values here): invalid value
sudo: error initializing audit plugin sudoers_audit" message, and ~20% chance of succeeding as expected. Unbinding the machine from LDAP fixes the problem, presumably because doing so reduces the number of groups for the user. Local admins were never affected. Creating an /etc/sudo.conf file that consists of the line "Set group_source dynamic" also fixes things for network users. We were seeing this on dozens of machines in our environment, and had been restricting the update for others as a result. Very relieved to have found the sudo.conf workaround here.

Comment 7 Todd C. Miller 2021-03-02 13:50:38 MST

This sounds like a recent macOS bug.  I tested sudo 1.9.4p1 on macOS 10.15.7 (I believe) and it worked for large numbers of groups.  However, those were all local users.

Going forward I think the safest thing is to make "group_source dynamic" the default on macOS, which is what I plan to do for sudo 1.9.6.