Bugzilla – Bug 946
the form %group fails when the user belongs to too many groups
Last modified: 2021-03-02 13:50:38 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.
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.
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.
This is fixed by the following commit: https://www.sudo.ws/repos/sudo/rev/2e7d3c3cf18b
Fixed in sudo 1.9.4p1
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.
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.
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.