Ned Deily <n...@acm.org> added the comment:
The problem Stephen is seeing with the buildbot machine is ABI-dependent; the
behavior of getgroups(2) changed in 10.6. You can demonstrate this all on a
10.6 system. Open a terminal session and verify the process's groups:
$ id -G
20 40200 401 204 100 98 80 61 12 403 40100 103
$ /usr/local/bin/python3.2 -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]
Now create a new user with System Preferences. One of the quirks here is that
OS X 10.5 and 10.6 create a new group for that user and assign other existing
users to that group. (The new group is one of the somewhat mysteriously named
com.apple.sharepoint.group.n groups.)
Still in the same terminal session after the new user/group was created and the
existing user name we are running under was automatically added to the new
group:
$ id -G
20 40200 401 204 100 98 80 61 12 403 40100 402 103
$ # note: new group membership 402 = com.apple.sharepoint.group.1
$ now test with 3 Pythons built from the same source, py3k tip:
$ cd ../../sdk10-4/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]
$ cd ../../sdk10-5/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]
$ cd ../../sdk10-6/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 402, 103]
Only the version built with a deployment target of 10.6 - that is, using the
10.6 SDK and the 10.6 ABI - reflects the updated grouplist. And that
difference can be seen, as Alexander noted earlier, in the symbols referenced.
An nm ./python | grep getgroups for each shows:
U _getgroups$DARWIN_EXTSN
for the 10.6 deployment target version but
U _getgroups
for the 10.5 and 10.4 targeted versions.
So unless building for a deployment target of 10.6 (or higher), it is to be
expected that the output of /usr/bin/id will not match the results of
getgroups(2) if the user's group membership changes during the run (as can
happen when another user is created or deleted).
This particular problem should only be an issue when running on 10.5 and higher
and using a 10.5 or earlier ABI. On 10.4, neither getgroups(2) (as expected)
nor /usr/bin/id see updates to group memberships made during the lifetime of
the parent terminal session; starting a new login terminal session does see the
updates.
Also note that this issue would be observable with all existing current
python.org OS X installers running on 10.5 or 10.6 as most have been built with
a 10.3 deployment target while 2.7 also provides an additional 32-/64-bit one
with a 10.5 deployment target. (I believe Ronald intends to build future
32-/64-bit installers with a 10.6 deployment target so they would be the first
to not be subject to this issue.)
FTR, here are the configure options I used for each build:
./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk
--with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.4
./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk
--with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.5
./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk
--with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.6
----------
nosy: +ned.deily
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
