[kerny]

Any third party code can just read your credentials file and POST it to remote server.

[yrro]

Bold of you to assume my third party code runs with the same UID and SELinux label as my credentials-handling code.

(I wish, it's April 1 after all!)

[josephcsible]

If the third party code runs with a different UID, then it can't read the environment either.

[yrro]

Unless it has DAC override or other capabilities. Belt and braces!

[josephcsible]

If it has DAC override, then it can read your credentials file just as easily as it can the environment.

[yrro]

Not if SELinux policy prevents it.

[yokaze]

File permissions allow finer granularity of access control. Environment variables are visible to any user in the system.

[_y5hn]

Not in any multi-user multi-process OS. You set environment variables in a process (ie. shell/CMD.EXE) and spawn child process (the program) from that parent. The environment variables will only be visible to those two processes.

[c0l0]

Linux disagrees; try

    strings /proc/*/environ

to see for yourself.

On Solaris/SunOS, you could use `pargs -e $PID`. And so on.

Having separate UIDs to run your processes A and B under shields either one from peeking at the other's environment, though. UNIX DAC is simple and powerful enough for MOST security concerns, I would argue.

[josephcsible]

> Environment variables are visible to any user in the system.

This is completely false in any modern OS. You can only see environment variables of your own processes.

[fps_doug]

Unset them after right after evaluation.

[mrkeen]

That's not where the credentials are stored.