News for hackers. Stuff that matters.
Re:Conventions for Command Line Options by ucarion on Saturday August 01, 2020 @04:05PM (#24023460)
Another nice thing about env vars is that they don't appear in the process table, unlike argv. For many applications, that makes them a suitable place to inject secrets, and makes them convenient to inject via wrapper tools.

For instance, the fact that the aws(1) cli tool and the AWS SDKs by default take IAM creds from AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc. means that you can write programs like aws-vault (https://github.com/99designs/aws-vault) which can acquire a temporary AWS session and then execute another command with the creds injected in the standard AWS_... env vars. For instance:

    aws-vault exec prod-read -- aws s3 ls
    aws-vault exec stage-admin -- ./my-script-that-uses-the-aws-sdk-internally
Also, passing arguments as env vars is part of the "12-factor app" design (https://12factor.net/config). That page has some good guidance.
Re:Conventions for Command Line Options by fanf2 on Saturday August 01, 2020 @06:10PM (#24024324)
The environment does appear in the process table: see `ps e` on Debian at https://manpages.debian.org/buster/procps/ps.1.en.html or ps -e on BSD at https://www.freebsd.org/cgi/man.cgi?query=ps&apropos=0&sekti... or pargs -e on Solaris at https://www.unix.com/man-page/opensolaris/1/pargs
Re:Conventions for Command Line Options by yjftsjthsd-h on Saturday August 01, 2020 @05:35PM (#24024081)
It's protected by at least uid, but `/proc/$PID/environ` does exist, and it might be exposed other ways, too.
Re:Conventions for Command Line Options by thayne on Saturday August 01, 2020 @08:11PM (#24025118)
That's actually a bad thing for non-secure arguments, and environment variables aren't much better for secure arguments.