• jet@hackertalks.com
    link
    fedilink
    English
    arrow-up
    66
    arrow-down
    1
    ·
    7 months ago

    But with one key difference: it’s *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

      • intrepid
        link
        fedilink
        arrow-up
        18
        ·
        7 months ago

        Unfortunately, this is about as easy as it gets. Practically though, it isn’t going to matter. It sounds like run0 will be a drop-in replacement for sudo. We will know for sure in about 3 days (at the rate at which they assimilate features).

      • anyhow2503@lemmy.world
        link
        fedilink
        arrow-up
        16
        arrow-down
        1
        ·
        7 months ago

        I would fucking hope not. TERM is explicitly passed along as the only exception, which is the only sensible default for temporary privilege elevation in a shell.

      • intrepid
        link
        fedilink
        arrow-up
        8
        arrow-down
        2
        ·
        7 months ago

        Sudo also blocks almost all environment variables, with the option to set or copy them on demand. I assume that run0 will have similar facilities to propagate variables on demand.

        PS: This is my technical understanding. Personally, I don’t like systemd eating up all the other utilities.