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 owsla
Recipients
Date 2007-07-08.13:51:00
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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;
History
Date User Action Args
2007-08-23 14:58:19adminlinkissue1747858 messages
2007-08-23 14:58:19admincreate