On Fedora 8 and 10 using Python 2.5.1 and 2.5.2 (64 bit):

$ grep nfsnobody /etc/passwd
nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin

So the UID of nfsnobody is 4294967294 (-2 if viewed as signed 32-bit int).

>>> import pwd, os
>>> print pwd.getpwnam('nfsnobody').pw_uid
4294967294
>>> os.chown('some file', pwd.getpwnam('nfsnobody').pw_uid,
pwd.getpwnam('nfsnobody').pw_gid)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

The reason for this error is that os.chown uses the "i" format to
convert the second and third arguments.  But the valued do not fit in a
32-bit signed integer.  uid_t and gid_t are defined as unsigned
quantities on this system.

The bug does not occur on 32 bit Fedora since there the uid and gid of
nfsnobody are 65534.

This was already corrected by r61540, and will be released with 2.5.3
and 2.6.2.

BUT -- fchown() was not modified. patch is similar to r61540, but I
don't know how to test:

Index: posixmodule.c
===================================================================
--- posixmodule.c	(revision 67068)
+++ posixmodule.c	(working copy)
@@ -1902,9 +1902,10 @@
 static PyObject *
 posix_fchown(PyObject *self, PyObject *args)
 {
-	int fd, uid, gid;
+	int fd;
+	long uid, gid;
 	int res;
-	if (!PyArg_ParseTuple(args, "iii:chown", &fd, &uid, &gid))
+	if (!PyArg_ParseTuple(args, "ill:fchown", &fd, &uid, &gid))
 		return NULL;
 	Py_BEGIN_ALLOW_THREADS
 	res = fchown(fd, (uid_t) uid, (gid_t) gid);

2^31-2 doesn't fit in long on 32 bits CPU. On my Linux box, uid_t is an 
unsigned integer (32 bits unsigned integer). Why not using "unsigned 
int"? chown prototype:

   int chown(const char *path, uid_t owner, gid_t group);

I'm sure you meant 2^32-2 ;-).

The "fix" to use long doesn't seem right to me either.  unsigned int is
a better match with uid_t and gid_t.

There is not only chown! There are also lchown(), fchown(), stat() and 
lstat().

Attached patch:
 - use "unsigned int" to store Windows st_uid/st_gid in the win32_stat 
structure
 - use PyLong to store an unsigned group in the stat result (because 
2^32-2 doesn't fit in a PyInt)
 - use "unsigned int" (instead of long) for uid/gid in chown, lchown 
and fchown

Note: *chown() accepts -1 for an argument, eg. chown("file", 10, -1) 
only changes the user group.

I tested my patch (for Python trunk) on Ubuntu Gutsy with a 32 bits 
CPU: chown(), lchwon(), fchown(), stat() and lstat() works as expected 
(support identifier > 2**31-1).

Anyone available for a patch review? Do you need anything else: tests, 
documentation updates, etc.?

The documentation for PyArg_ParseTuple states that the "I" code doesn't
do any overflow checking. Does it mean the input parameters can be
silently truncated?

pitrou> The documentation for PyArg_ParseTuple states that the 
pitrou> "I" code doesn't do any overflow checking. Does it mean 
pitrou> the input parameters can be silently truncated?

I'm sorry, but you're right :-) My patch was wrong. New patch 
introduces functions parse_uid() and parse_gid() doing the right thing 
to get an unsigned uid and gid. I reused the parsing code from 
posix_setgroups().

Oops, i forgot to ignore space changes in my diff... new patch.

New patch using PyNumber_Index()+PyLong_AsLong() for parse_uid() and 
parse_gid() as proposed by antoine (on IRC).

Changes between python trunk and posix_unsigned_uid-3.patch:

- os.chown() and os.fchown() accepts uid and gid > 2^31: identifiers 
can be in [-1; 2^32-1] (-1 means: don't change uid/gid)

- fix os.*stat(): st_uid and st_gid are unsigned long integers (in [0; 
2^32-1]) instead of signed integers

- os.chown(), os.fchown() and os.setgroups() accepts any objects 
implementing __index__() method (instead of just int/long) and display 
the valid range on error ("group id is to big" => "group id is not in 
range [-1; 2^32-1]")

I'm not sure hardcoding "2^32 - 1" in the error message is a good idea.

I also think it would be nice to have tests for the "-1" special value:
- check that chown(-1, current_gid) succeeds (and leaves the uid intact)
- check that chown(current_uid, -1) succeeds (and leaves the gid intact)

See also #3586: "pwd.getpwnam('nobody') produces incorrect results if
sizeof(uid_t) < sizeof(long)" (now closed).