Replace exec-suid environ modes with env overrides

[ConnorNelson]

Summary

• keep --environ=none/all/safe temporarily as deprecated compatibility options
• add repeated --env KEY=VALUE shebang overrides for explicit environment variables
• source the default safe PATH from /etc/environment, with a Debian/Ubuntu root PATH fallback
• skip /etc/environment PATH lookup when --env PATH=... is explicitly provided

Rationale

exec-suid previously required PATH to be present in /proc/1/environ. That works when PID 1 is the container process, but it breaks in runtimes where PID 1 is platform infrastructure or a minimal init without image ENV values. /etc/environment is a better image-owned source for this value, and a fixed fallback keeps safe mode usable even when that file is absent.

The new --env option intentionally only supports explicit KEY=VALUE assignments. The shebang line is still split on whitespace, so values containing whitespace are intentionally not supported.

The fallback PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, matching Debian/Ubuntu's root ENV_SUPATH without Ubuntu's snap-specific suffix. Python's os.defpath is narrower (/bin:/usr/bin), and Ubuntu sudo's secure_path adds /snap/bin, so the Debian root path is the better general-purpose default here.

Validation

• docker build -t exec-suid-env-pr /tmp/exec-suid-pr && docker run --rm exec-suid-env-pr passes: 19 tests
• git diff --check

Note: cargo fmt --check was not applied because the existing upstream source is not rustfmt-formatted and rustfmt would rewrite unrelated lines.

[zardus]

Can we keep backwards compatibility in the normal case? We have a lot of challenges using this now...

[ConnorNelson]

Sure, I'll mark it deprecated instead for now, until we've stopped using the feature.

I just took a quick glance at:

• https://github.com/search?q=org%3Apwncollege+--environ%3Dnone&type=code
• https://github.com/search?q=org%3Apwncollege+--environ%3Dall&type=code

My guess is it won't be so difficult to have some agents migrate the code in the future. I think --environ=none is kind of silly. I know I've seen some agents think they need to use it to be safe, but you really don't: the default is safe.

And --environ=all is of course inherently unsafe and can always lead to problems. Of course, we have challenges that like that and/or accept that limitation. I'm not sure if a custom really dumb exec-suid makes the most sense for those challenges (it would be really easy to write), or maybe if all of them really just want --env PATH=$PATH or something like that, we can add support for that.