Alexey Izbyshev <izbys...@ispras.ru> added the comment:
> 1) This is intentional, this is for dropping privileges before running some > (possibly untrusted) command, we do not want to leave a path for the > subprocess to gain root back. If there is a subprocess that needs root for > some operations, it would presumably have the ability to drop privileges > itself, and would not need the python script to do it before running it. > 2) While POSIX leaves it unspecified what changes are permitted for an > unprivileged process, these are permitted for a privileged process, which is > the main use case for this functionality. In the case the OS does not support > it for an unpriviliged process, the syscall would fail with EPERM, which can > be handled from the calling python code. Thanks for your explanation. In case of a privileged process, the behavior of setreuid/setregid/setgroups does seem well-defined. But setuid/setgid change all ids (real, effective, saved) too in this case. Do you prefer setreuid/setregid because they provide stricter semantics in non-privileged processes compared to setuid/setgid? (The latter ones change the effective id only, potentially preserving the process ability to switch ids later). > I am fine removing the workaround, and allowing it to fail with EPERM. > Perhaps we could find another way around this for running the tests in an > unprivileged environment, or just leave the test only running the EPERM > case... > I could change the API to have have group= and supp_groups= if you prefer. Personally, I do prefer separate arguments because subprocess is a relatively low-level module and tends to expose underlying operations, so it seems logical to have a knob that maps to setgid() and another one that maps to setgroups(). @gregory.p.smith: what do you think about it? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36046> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
