Gregory P. Smith g...@krypto.org added the comment:
a test would still be a good thing but this should be fixed regardless.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6873
Gregory P. Smith g...@krypto.org 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
Boya Sun boya@case.edu 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
Changes by Gregory P. Smith g...@krypto.org:
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6873
___
Changes by Gregory P. Smith g...@krypto.org:
--
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6873
___
___
Python-bugs-list
Boya Sun boya@case.edu 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
Martin v. Löwis mar...@v.loewis.de 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 rep...@bugs.python.org
http://bugs.python.org/issue6873
Martin v. Löwis mar...@v.loewis.de 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.
Martin v. Löwis mar...@v.loewis.de 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
STINNER Victor victor.stin...@haypocalc.com 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
Boya Sun boya@case.edu 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
STINNER Victor victor.stin...@haypocalc.com 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:
Martin v. Löwis mar...@v.loewis.de 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
Boya Sun boya@case.edu 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
Changes by Boya Sun boya@case.edu:
Removed file: http://bugs.python.org/file14869/patch.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6873
___
New submission from Boya Sun boya@case.edu:
posix_lchown(PyObject *self, PyObject *args)
{
...
int uid, gid;
...
if (!PyArg_ParseTuple(args, etii:lchown,
Py_FileSystemDefaultEncoding, path,
uid, gid))
16 matches
Mail list logo
