This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, flox, l0nwlf, loewis, michael.foord, orsenthil, r.david.murray, ronaldoussoren
Date 2010-06-23.15:39:42
SpamBayes Score 0.00046217302
Marked as misclassified No
Message-id <>
Reposting from python-dev. See "os.getgroups() on MacOS X" <>.

On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren <> wrote:
>>> * [Ronald's proposal] results in posix.getgroups not reflecting results of posix.setgroups
>> This effectively substitutes getgrouplist called on the current user
>> for getgroups.  In 3.x, I believe the correct action will be to
>> provide direct access to getgrouplist which is while not POSIX (yet?),
>> is widely available.
> I don't mind adding getgrouplist, but that issue is seperator from this one. BTW. Appearently getgrouplist is posix
> (<>), although this isn't a
> requirement for being added to the posix module.

(The link you provided leads to "Linux Standard Base Core
Specification," which is different from POSIX, but the distinction is
not relevant for our discussion.)

> It is still my opinion that the second option is preferable for better compatibility with system tools, even if the patch
> is more complicated and the library function we use can be considered to be broken.

Let me try to formulate what the disagreement is.  There are two
different group lists that can be associated with a running process:
1) The list of current supplementary group IDs maintained by the
system for each process and stored in per-process system tables; and
2) The list of the groups that include the uid under which the process
is running as a member.

The first list is returned by a system call getgroups and the second
can be obtained using system database access functions as follows:

pw = getpwuid(getuid())
getgrouplist(pw->pw_name, ..)

The first list can be modified by privileged processes using setgroups
system call, while the second changes when system databases change.

The problem that _DARWIN_C_SOURCE introduces is that it replaces
system getgroups with a database query effectively making the true
process' list of supplementary group IDs inaccessible to programs.
See source code at

The problem is complicated by the fact that OSX true getgroups call
appears to truncate the list of groups to NGROUPS_MAX=16.  Note,
however that it is not clear whether the system call truncates the
list or the underlying process tables are limited to 16 entries and
additional groups are ignored when the process is created.

In my view, getgroups and getgrouplist are two fundamentally different
operations and both should be provided by the os module.  Redefining
os.getgroups to invoke getgrouplist instead of system getgroups on one
particular platform to work around that platform's system call
limitation is not right.
Date User Action Args
2010-06-23 15:39:45belopolskysetrecipients: + belopolsky, loewis, ronaldoussoren, orsenthil, r.david.murray, michael.foord, flox, l0nwlf
2010-06-23 15:39:45belopolskysetmessageid: <>
2010-06-23 15:39:43belopolskylinkissue7900 messages
2010-06-23 15:39:42belopolskycreate