[issue6873] posix_lchown: possible overflow of uid, gid

Gregory P. Smith added the comment: a test would still be a good thing but this should be fixed regardless. -- resolution: -> accepted status: open -> closed ___ Python tracker

[issue6873] posix_lchown: possible overflow of uid, gid

Boya Sun added the comment: Gregory, I discovered this bug by static analysis, so I do not have a system that this bug is actually triggered. But I am happy to see the fix applied since this makes code safer. It would be great if anyone could write a test case that cause uid and gid to overf

[issue6873] posix_lchown: possible overflow of uid, gid

Gregory P. Smith added the comment: I applied the same fix that was applied to chown in trunk r77007 for lchown and fchown. Could you test it on a platform where it previously failed? The existing code might still have issues if there are platforms where uid_t and gid_t are unsigned but not

[issue6873] posix_lchown: possible overflow of uid, gid

Changes by Gregory P. Smith : -- priority: -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue6873] posix_lchown: possible overflow of uid, gid

Changes by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list maili

[issue6873] posix_lchown: possible overflow of uid, gid

Martin v. Löwis added the comment: Yes, it looks correct now. I still wish it could be tested on a system where the problem actually occurs. -- ___ Python tracker ___ __

[issue6873] posix_lchown: possible overflow of uid, gid

Boya Sun added the comment: Martin, Corrected the patch accordingly. Can you verify whether the fix is correct or not now? Boya -- Added file: http://bugs.python.org/file14900/patch_6873.diff ___ Python tracker

[issue6873] posix_lchown: possible overflow of uid, gid

Martin v. Löwis added the comment: > You are saying that if I pass a long to the i argument parser it will > cause a problem. But if I passed a int, it will be same as before and > overflow will not be detected at all. Correct. So you should use the l argument parser. -- __

[issue6873] posix_lchown: possible overflow of uid, gid

Boya Sun added the comment: Martin, I am sorry that I do not have a system where this code actually triggered a problem, since this bug is discovered by a *static* analysis tool that is recently developed by our research group, which finds code segments that are similar to a previously fixed bu

[issue6873] posix_lchown: possible overflow of uid, gid

STINNER Victor added the comment: @loewis: I don't think that the explicit cast is required. posix_setuid() has no explicit cast. But I would also prefer an explicit cast (just for the readability). -- ___ Python tracker

[issue6873] posix_lchown: possible overflow of uid, gid

Martin v. Löwis added the comment: I think the new patch is still incorrect. You now pass long variables into the i argument parser. Also, I would expect that compilers prefer to see an explicit cast from long to uid_t, in case it's a truncating cast. Can you try your patch on a system where

[issue6873] posix_lchown: possible overflow of uid, gid

Changes by Boya Sun : Removed file: http://bugs.python.org/file14869/patch.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue6873] posix_lchown: possible overflow of uid, gid

Boya Sun added the comment: Martin, The reason why I think there is a possible overflow is that according to issue 5705, uid/gid overflows are fixed in the following functions: posix_setegid, posix_setreuid(), posix_setregid(), posix_setgid(). So I think a similar fix should also be applied to

[issue6873] posix_lchown: possible overflow of uid, gid

Martin v. Löwis added the comment: The patch is incorrect. Why do you think there is an overflow? There is none in the call to ParseTuple: the i argument parser expects a signed int*; passing a long* will break on systems where sizeof(int)!=sizeof(long) (such as typical 64-bit Unix). In addi

[issue6873] posix_lchown: possible overflow of uid, gid

STINNER Victor added the comment: posix modules contains a lot of function parsing uid_t / gid_t types. I would be nice to factorize the code: create a function to get an uid_t, and another to get a gid_t. I don't know the name of such callback, but it's used with: PyArg_ParseTuple(args, "...O&.

[issue6873] posix_lchown: possible overflow of uid, gid

New submission from Boya Sun : posix_lchown(PyObject *self, PyObject *args) { ... int uid, gid; ... if (!PyArg_ParseTuple(args, "etii:lchown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) ...