[issue36046] support dropping privileges when running subprocesses
New submission from Patrick McLean : Currently when using python to automate system administration tasks, it is useful to drop privileges sometimes. Currently the only way to do this is via a preexec_fn, which has well-documented problems. It would be useful to be able to pass a user and groups arguments to subprocess.popen. -- components: Library (Lib) messages: 336033 nosy: patrick.mclean priority: normal severity: normal status: open title: support dropping privileges when running subprocesses type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36046] support dropping privileges when running subprocesses
Change by Patrick McLean : -- keywords: +patch pull_requests: +11974 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36046] support dropping privileges when running subprocesses
Patrick McLean added the comment: Alexey, here are my responses to your points: 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. 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. -- ___ Python tracker <https://bugs.python.org/issue36046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36046] support dropping privileges when running subprocesses
Patrick McLean added the comment: > 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). Yes, exactly. The stricter semantics provide stronger security guarantees. The idea is to run code in an unprivileged context in a way that the code has no way to regain privileges. -- ___ Python tracker <https://bugs.python.org/issue36046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36046] support dropping privileges when running subprocesses
Patrick McLean added the comment: I have updated the pull request to include 'group' and 'extra_groups' as separate parameters. -- ___ Python tracker <https://bugs.python.org/issue36046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
