subprocess.call(..., user=xx, group=xxx) is not able to gain privileges

[socketpair]

#!/usr/bin/python3

from os import getresuid, initgroups, setresgid, setresuid
from pwd import getpwnam
from subprocess import check_call


def drop_permissions():
    user = 'nobody'
    info = getpwnam(user)
    uid = info.pw_uid
    gid = info.pw_gid

    assert uid
    assert gid

    initgroups(user, gid)
    setresgid(gid, gid, gid)
    setresuid(uid, uid, 0)


def run_privileged_proc():
    def restore():
        setresuid(0, 0, 0)
        setresgid(0, 0, 0)
        initgroups('root', 0)

    check_call(['id'], preexec_fn=restore)


def main():
    assert getresuid() == (0, 0, 0)
    # This on works (dropping permissions in child process)
    check_call(['id'], user=65534, group=65534)
    drop_permissions()

    # This one works:
    run_privileged_proc()

    # This does not:
    check_call(['id'], user=0, group=0)


main()

for the last subprocess, strace of child process:

set_robust_list(0x7eff7bfaea20, 24)     = 0
close(7)                                = 0
close(9)                                = 0
close(11)                               = 0
dup2(6, 0)                              = 0
dup2(8, 1)                              = 1
dup2(10, 2)                             = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK, sa_restorer=0x7eff7b83ea30}, {sa
rt_sigaction(SIGXFSZ, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK, sa_restorer=0x7eff7b83ea30}, {sa
setgroups(0, [])                        = -1 EPERM (Операция не позволена)
write(12, "OSError:", 8)                = 8
write(12, "1", 1)                       = 1
write(12, ":", 1)                       = 1
write(12, "noexec", 6)                  = 6
exit_group(255)                         = ?
+++ exited with 255 +++

Python 3.10.7

Linked PRs

• gh-100163: allow re-assuming root privileges on subprocess invocations #134400

[socketpair]

Why?

Because sequences to up and down privileges are DIFFERENT (reversed order of functions call).

To down privileges (this logic is hard-coded in Python now):

# have to find username by uid or....
# we definitely have to drop supplementary groups. either to empty list or new user's groups
initgroups(username, gid) 
setresgid(gid, gid, gid)
setresuid(uid, uid, uid)

To up:

setresuid(0, 0, 0)
setresgid(0, 0, 0)
initgroups('root', 0)  # or, replace with os.setgroups([])

I think, Python should detect what caller wants (up or down) and chose the correct sequence.

Possibly add as_superuser: bool = False (I don't like adding one more kwarg to subprocess)

[duaneg]

Because sequences to up and down privileges are DIFFERENT (reversed order of functions call).

That is true, but is not the only issue...

The _posixsubprocess.c code uses setreuid not setresuid, so even if we switch around the order when switching to uid 0 and make the setreuid call first it will still fail. To make this work we would have to change the code to using setresuid/setresgid instead of setreuid/setregid as well as changing the uid first when switching from an unprivileged user to root.

I have a WIP patch which does all that but I'm not completely confident this won't have any unintended side-effects, won't change behaviour of any existing working code, and is worth the extra complexity/risk. If the maintainers (CC @giampaolo and @gpshead) think it might be worth doing I'll polish it off and push it out for consideration. If not this should probably be closed as "not planned": anyone needing to drop and then reacquire perms can always do it manually, e.g. by using preexec_fn as in the OP's example.

[gpshead]

Yeah, preexec_fn= is a workaround... that we don't want but do not have a nice way to get rid of despite its footgun reliabiity/deadlock problems.

@duaneg - Could you make a Draft PR for what you were thinking at least for reference here even before anything has been decided?

[duaneg]

Right, that workaround does seem inherently unsafe. I've polished up the change and will push it out shortly. Unfortunately I don't think it is practical to unit test, as it requires root privileges.