[ python-Bugs-1747858 ] chown broken on 64bit

[SourceForge.net]

Bugs item #1747858, was opened at 2007-07-04 10:21
Message generated for change (Comment added) made by owsla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit

Initial Comment:
python-2.5 on fedora fc7 x86_64:

os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517)

os.chown doesn't like that:
 os.chown ('shit', 4294967294, 4294967294) 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

----------------------------------------------------------------------

Comment By: Andrew Ferguson (owsla)
Date: 2007-07-08 09:51

Message:
Logged In: YES 
user_id=19094
Originator: NO

No, the return value of stat is correct. For that it does:
PyInt_FromLong((long)st->st_uid) in _pystat_fromstructstat(STRUCT_STAT *st)
(same file, posixmodule.c). Fedora has been defining the UID of the
nfsnobody user on 32-bit to be 65534 (USHRT_MAX - 1) and on 64-bit to be
4294967294 (UINT_MAX - 1), assuming 32-bit ints. So, yes, this absurdly
high UID is real.

So that chown('foo', -1, -1) makes sense, the UID that would be "(uid_t)
-1" is reserved. That's why Fedora went for "(uid_t) -2".

I think a patch should look something like:

$ diff -p posixmodule.c.orig posixmodule.c 
*** posixmodule.c.orig  Sun Jul  8 09:43:50 2007
--- posixmodule.c       Sun Jul  8 09:48:27 2007
*************** static PyObject *
*** 1826,1834 ****
  posix_chown(PyObject *self, PyObject *args)
  {
        char *path = NULL;
!       int uid, gid;
        int res;
!       if (!PyArg_ParseTuple(args, "etii:chown",
                              Py_FileSystemDefaultEncoding, &path,
                              &uid, &gid))
                return NULL;
--- 1826,1834 ----
  posix_chown(PyObject *self, PyObject *args)
  {
        char *path = NULL;
!       unsigned int uid, gid;
        int res;
!       if (!PyArg_ParseTuple(args, "etII:chown",
                              Py_FileSystemDefaultEncoding, &path,
                              &uid, &gid))
                return NULL;

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-07-08 06:29

Message:
Logged In: YES 
user_id=21627
Originator: NO

Notice that the value really is -2.

It's important to find out how uid_t is defined on the platform; 
it may be that the return value of stat is already incorrect.

Merely changing the variables to uid_t and gid_t is not enough,
since then ParseTuple would stop working correctly.

Is anybody interested in providing a patch?

----------------------------------------------------------------------

Comment By: Andrew Ferguson (owsla)
Date: 2007-07-04 11:04

Message:
Logged In: YES 
user_id=19094
Originator: NO

Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables
are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which
are mapped to 'unsigned int' on at least some Unix platforms (I haven't
checked extensively.)

The wrinkle here is that chown() needs to be able to handle the case of
uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1,
-1) is valid, but so is os.chown(4294967294, 4294967294).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470