macOS Mojave: setgroups(501) failed: Too many extra groups
Hello,
I have recently upgraded to macOS 10.14 (Mojave) and am running into an issue where one use can no longer log into dovecot via imap. Log shows
Oct 11 08:10:27 imap(hwr)<12659>
and indeed, the user is in 17 groups, which is more than NGROUPS_MAX (16). Another user with << 16 groups can log in fine. Unfortunately it is not (easily) doable to reduce the number of groups, as macOS seems to set them internally.
Is there a config option that I am missing to work around this?
Looking at the source, I see this is handled in src/lib/restrict-access.c::fix_groups_list(), where above the call to setgroups() a gid_list2 is constructed. I wonder if one could have a config option to prevent adding all those extra groups, which then make the call to setgroups() fail
Any help appreciated Heiko
-- hwr@pilhuhn.de m:0179/207 4919 b:http://pilhuhn.blogspot.com
On 11.10.2018 09:28, Heiko W. Rupp wrote:
Hello,
I have recently upgraded to macOS 10.14 (Mojave) and am running into an issue where one use can no longer log into dovecot via imap. Log shows
Oct 11 08:10:27 imap(hwr)<12659>
: Fatal: setgroups(501) failed: Too many extra groups and indeed, the user is in 17 groups, which is more than NGROUPS_MAX (16). Another user with << 16 groups can log in fine. Unfortunately it is not (easily) doable to reduce the number of groups, as macOS seems to set them internally.
Is there a config option that I am missing to work around this?
Looking at the source, I see this is handled in src/lib/restrict-access.c::fix_groups_list(), where above the call to setgroups() a gid_list2 is constructed. I wonder if one could have a config option to prevent adding all those extra groups, which then make the call to setgroups() fail
Any help appreciated Heiko
Not trivially. We would need to know which groups to drop and which not.
Aki
On Thu, Oct 11, 2018 at 09:51:34AM +0300, Aki Tuomi wrote:
Looking at the source, I see this is handled in src/lib/restrict-access.c::fix_groups_list(), where above the call to setgroups() a gid_list2 is constructed. I wonder if one could have a config option to prevent adding all those extra groups, which then make the call to setgroups() fail
Not trivially. We would need to know which groups to drop and which not.
Looking at id output
id uid=501(hwr) gid=20(staff) groups=20(staff),6(mail),12(everyone),61(localaccounts),80(admin),98(_lpadmin),500(users),701(com.apple.sharepoint.group.1),702(com.apple.sharepoint.group.2),30(_keytabusers),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),103(com.apple.access_screensharing-disabled),104(com.apple.access_ssh-disabled)
it seems that all the com.apple ones can easily be dropped. What about a config list, that the admin can set with a list of gids, that can be dropped/are not added to gid_list2 ?
Heiko
On 11.10.2018 10:08, Heiko W. Rupp wrote:
On Thu, Oct 11, 2018 at 09:51:34AM +0300, Aki Tuomi wrote:
Looking at the source, I see this is handled in src/lib/restrict-access.c::fix_groups_list(), where above the call to setgroups() a gid_list2 is constructed. I wonder if one could have a config option to prevent adding all those extra groups, which then make the call to setgroups() fail
Not trivially. We would need to know which groups to drop and which not. Looking at id output
id uid=501(hwr) gid=20(staff) groups=20(staff),6(mail),12(everyone),61(localaccounts),80(admin),98(_lpadmin),500(users),701(com.apple.sharepoint.group.1),702(com.apple.sharepoint.group.2),30(_keytabusers),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),103(com.apple.access_screensharing-disabled),104(com.apple.access_ssh-disabled)
it seems that all the com.apple ones can easily be dropped. What about a config list, that the admin can set with a list of gids, that can be dropped/are not added to gid_list2 ?
Heiko
Maybe. Have to see when we can implement it though. It could probably leverage the min/max_gid setting.
Aki
On Thu, Oct 11, 2018 at 10:55:39AM +0300, Aki Tuomi wrote:
Maybe. Have to see when we can implement it though. It could probably leverage the min/max_gid setting.
Actually that was a great hint.
Setting last_valid_gid = 100 in the config and restarting helped. Having a filter-list instead of fixed upper/lower bounds would be more flexible. I guess though that in reality most systems/setups have ranges for different kinds of groups, so that the first/last_valid_gid could be applied.
Thanks Heiko
On 11 Oct 2018, at 7:35 pm, Heiko W. Rupp hwr@pilhuhn.homeip.net wrote:
On Thu, Oct 11, 2018 at 10:55:39AM +0300, Aki Tuomi wrote:
Maybe. Have to see when we can implement it though. It could probably leverage the min/max_gid setting.
Actually that was a great hint.
Setting last_valid_gid = 100 in the config and restarting helped. Having a filter-list instead of fixed upper/lower bounds would be more flexible. I guess though that in reality most systems/setups have ranges for different kinds of groups, so that the first/last_valid_gid could be applied.
Thanks Heiko
Hi Heiko,
I’m also trying to set up Dovecot on a Mojave system.
Would you mind leting me know what your settings are?
Ie output of:
dovecot -n
Many thanks,
James.
On 11 Oct 2018, at 5:28 pm, Heiko W. Rupp
Hello,
I have recently upgraded to macOS 10.14 (Mojave) and am running into an issue where one use can no longer log into dovecot via imap. Log shows
Oct 11 08:10:27 imap(hwr)<12659>
: Fatal: setgroups(501) failed: Too many extra groups ... Any help appreciated Heiko
This came up on the list a few months ago. See thread with subject "dying on osx” on 11 August and 4 September 2018.
The only way I managed to get it to work was by changing default_login_user and default_internal_user to my username.
As you say, wasn’t an issue with earlier versions of macOS X.
Any solution would be most appreciated.
James.
participants (4)
-
Aki Tuomi
-
Heiko W. Rupp
-
Heiko W. Rupp
-
James Brown