You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
os.getgrouplist() can fail on macOS if the user has more than 17 groups #84195
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2020-03-24.17:51:27.264>created_at=<Date2020-03-19.16:04:54.967>labels= ['OS-mac', '3.7', '3.8', '3.9', 'type-feature', 'tests']
title='os.getgrouplist() can fail on macOS if the user has more than 17 groups'updated_at=<Date2020-03-24.17:51:27.264>user='https://github.com/corona10'
changed the title [-]os.getgrouplist can raise OSError during the Display build info[/-][+]os.getgrouplist() fails on macOS of GH Actions (Azure)[/+]on Mar 19, 2020
changed the title [-]os.getgrouplist can raise OSError during the Display build info[/-][+]os.getgrouplist() fails on macOS of GH Actions (Azure)[/+]on Mar 19, 2020
This error has to do with the number of groups a particular user is associated with. We’ve squashed similar bugs in the past but it looks like something has changed again in recent releases of macOS. It’s not Azure specific.
changed the title [-]os.getgrouplist() fails on macOS 10.15 (Catalina) if the user has more than 17 groups[/-][+]os.getgrouplist() can fail on macOS if the user has more than 17 groups[/+]on Mar 23, 2020
changed the title [-]os.getgrouplist() fails on macOS 10.15 (Catalina) if the user has more than 17 groups[/-][+]os.getgrouplist() can fail on macOS if the user has more than 17 groups[/+]on Mar 23, 2020
Most likely this hasn't been an issue before is that 10.15 creates more groups for system services than the earlier versions did.
Aha, interesting. I updated my PR to remove mentions of the macOS version number. I just wrote "on macOS". Yeah, I wouldn't be surprised that the function always failed.
--
I'm not sure that the Linux implementation is correct. It rely on errno, whereas Linux manual page of getgrouplist() doesn't say anything about errno being set on error.
Moreover, on Linux, getgrouplist() can also fail with -1 if the group list is too small. In that case, ngroups is updated to the number of groups and so can be used to enlarge the list!
Moreover, on Linux, getgrouplist() can also fail with -1 if the group list is too small. In that case, ngroups is updated to the number of groups and so can be used to enlarge the list!
I tested by manually initializing ngroups to a value way lower than MAX_GROUPS (65536 on my Fedora 31): os.getgrouplist() raises OSError() with a random errno, getgrouplist() doesn't set errno on failure.
I wrote PR 19126 to fix the issue on all platforms. The glibc implementation is detected and used: use updated ngroups value (only if it's larger).
Ned: so Linux was also impacted, but Linux only has an issue with more than 65536 groups :-D macOS MAX_GROUPS is now only 16 (Python uses MAX_GROUPS+1)! Maybe MAX_GROUPS was reduced recently. I'm not sure.
Anyway, os.getgrouplist() does no longer depend on MAX_GROUPS hardcoded limit, but grow the group list dynamically. It should now work with any number of groups an all platforms (which provide the getgrouplist() function ;-)) on Python 3.7, 3.8 and master branches.
Thanks Dong-hee Na for the bug report and your PR.
Activity
corona10 commentedon Mar 19, 2020
example: https://github.com/python/cpython/pull/19073/checks?check_run_id=519539592
I suggest to not to add information for os.getgrouplist
if the OSError is raised.
corona10 commentedon Mar 19, 2020
or adding <OSError> might be great just like getpwuid
vstinner commentedon Mar 19, 2020
These errors are really strange.
Steve Dower: are you aware of anything recent change on the macOS job of Azure Pipelines / GH Actions.
pythoninfo:
---
os.uname: posix.uname_result(sysname='Darwin', nodename='Mac-1422.local', release='19.3.0', version='Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64', machine='x86_64')
platform.architecture: 64bit
platform.platform: macOS-10.15.3-x86_64-i386-64bit
---
Collection failed: exit with error
test_posix.test_getgrouplist() failed with:
======================================================================
ERROR: test_getgrouplist (test.test_posix.PosixTester)
----------------------------------------------------------------------
[-]os.getgrouplist can raise OSError during the Display build info[/-][+]os.getgrouplist() fails on macOS of GH Actions (Azure)[/+][-]os.getgrouplist can raise OSError during the Display build info[/-][+]os.getgrouplist() fails on macOS of GH Actions (Azure)[/+]ned-deily commentedon Mar 19, 2020
This error has to do with the number of groups a particular user is associated with. We’ve squashed similar bugs in the past but it looks like something has changed again in recent releases of macOS. It’s not Azure specific.
[-]os.getgrouplist() fails on macOS of GH Actions (Azure)[/-][+]os.getgrouplist() can fail on macOS[/+]10 remaining items
[-]os.getgrouplist() fails on macOS 10.15 (Catalina) if the user has more than 17 groups[/-][+]os.getgrouplist() can fail on macOS if the user has more than 17 groups[/+][-]os.getgrouplist() fails on macOS 10.15 (Catalina) if the user has more than 17 groups[/-][+]os.getgrouplist() can fail on macOS if the user has more than 17 groups[/+]vstinner commentedon Mar 23, 2020
Aha, interesting. I updated my PR to remove mentions of the macOS version number. I just wrote "on macOS". Yeah, I wouldn't be surprised that the function always failed.
--
I'm not sure that the Linux implementation is correct. It rely on errno, whereas Linux manual page of getgrouplist() doesn't say anything about errno being set on error.
Moreover, on Linux, getgrouplist() can also fail with -1 if the group list is too small. In that case, ngroups is updated to the number of groups and so can be used to enlarge the list!
vstinner commentedon Mar 23, 2020
test.pythoninfo of the macOS job on the PR:
os.getgrouplist: 20, 0, 12, 61, 79, 80, 81, 98, 264, 399, 701, 33, 100, 204, 250, 395, 398, 400
os.getgroups: 20, 0, 12, 61, 79, 80, 81, 98, 264, 399, 701, 33, 100, 204, 250, 395, 398, 400
So yeah, there are 18 groups ;-)
vstinner commentedon Mar 23, 2020
New changeset 8ec7370 by Victor Stinner in branch 'master':
bpo-40014: Fix os.getgrouplist() on macOS (GH-19118)
8ec7370
miss-islington commentedon Mar 23, 2020
New changeset 21bee0b by Miss Islington (bot) in branch '3.8':
bpo-40014: Fix os.getgrouplist() on macOS (GH-19118)
21bee0b
miss-islington commentedon Mar 23, 2020
New changeset 1cdc61c by Miss Islington (bot) in branch '3.7':
bpo-40014: Fix os.getgrouplist() on macOS (GH-19118)
1cdc61c
vstinner commentedon Mar 23, 2020
I tested by manually initializing ngroups to a value way lower than MAX_GROUPS (65536 on my Fedora 31): os.getgrouplist() raises OSError() with a random errno, getgrouplist() doesn't set errno on failure.
I wrote PR 19126 to fix the issue on all platforms. The glibc implementation is detected and used: use updated ngroups value (only if it's larger).
vstinner commentedon Mar 24, 2020
New changeset f5c7cab by Victor Stinner in branch 'master':
bpo-40014: Fix os.getgrouplist() (GH-19126)
f5c7cab
miss-islington commentedon Mar 24, 2020
New changeset 5753fc6 by Miss Islington (bot) in branch '3.7':
bpo-40014: Fix os.getgrouplist() (GH-19126)
5753fc6
miss-islington commentedon Mar 24, 2020
New changeset af6fd1f by Miss Islington (bot) in branch '3.8':
bpo-40014: Fix os.getgrouplist() (GH-19126)
af6fd1f
vstinner commentedon Mar 24, 2020
Ned: so Linux was also impacted, but Linux only has an issue with more than 65536 groups :-D macOS MAX_GROUPS is now only 16 (Python uses MAX_GROUPS+1)! Maybe MAX_GROUPS was reduced recently. I'm not sure.
Anyway, os.getgrouplist() does no longer depend on MAX_GROUPS hardcoded limit, but grow the group list dynamically. It should now work with any number of groups an all platforms (which provide the getgrouplist() function ;-)) on Python 3.7, 3.8 and master branches.
Thanks Dong-hee Na for the bug report and your PR.