David,

Can you unset "normal" priority from this issue.  Regardless of whether it is a crash or not a crash, this is a regression for which there is no user work-around.  It looks like "normal" priority makes the issue disappear from the top of "Show Open" search and this is inconvenient while the issue is being worked on.

On Tue, Feb 23, 2010 at 12:32 PM, Ronald Oussoren <report@bugs.python.org> wrote:
..
>        setgid(3);
>        setuid(502);
>        execl("/usr/bin/id", "/usr/bin/id", NULL);
..
> On OSX it prints the group information that's associated with the 502 > account in the user database, and only prints the expected values when > I call setuid(600), which is a UID that isn't in use on my system.
>

This looks like a bug (surprise!) in OSX' /usr/bin/id.  With a freshly compiled coreutils-8.4, your program behaves as you expect when using /usr/local/bin/id.
  

> This is both with and without setting _DARWIN_C_SOURCE and even when
> compiling with deployment target 10.4 and using the 10.4 SDK.

This is to be expected because your program only calls setgroups which is unaffected by _DARWIN_C_SOURCE settings.  Note that it will also fail regardless of compilation mode if you change 16 to 17.

> I'm therefore in favor of keeping _DARWIN_C_SOURCE and adding the
> workaround for a larger number of groups as implemented in
> os-getgroups.patch.

I don't understand the "therefore" part.  As you say, _DARWIN_C_SOURCE setting has no effect on your program, so what is the advantage of keeping it is posixmodule.c?

As I explained, with _DARWIN_C_SOURCE set,

"""
[OSX getgroups] is not getgroups at all and instead is effectively a call to getgrouplist(getpwuid(..)->pw_name, ..).  In other words, it reads the system database instead of the per-process list.
"""

Why do you think this is what users expect to get when calling posix.getgroups()?


> This means that using

It looks like the rest of your message was lost ...