Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Environment variables are a legacy mess: Let's dive deep into them

allvpv.org

Post reply on HN
Print view View original

11–20 of 194 posts

Re: Environment variables are a legacy mess: Let's dive deep into them

#11

Post by bbkane »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

Any good cross-platform and easy ways to share secrets without using environment variables?

Re: Environment variables are a legacy mess: Let's dive deep into them

#12

Post by skylurk »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

I've used keyring, but ultimately does not solve the issue of every application running under the same user.

https://pypi.org/project/keyring/

Re: Environment variables are a legacy mess: Let's dive deep into them

#13

Post by the__alchemist »

I get anxiety whenever I need to set an environment var on Linux. There are (somewhat distro-specific) ways that work properly, but the usual procedures you find online stops working once you reboot (or close the terminal I think?). They should add a simple env var GUI like Windows has that just works, and isn't terminal-specific. Windows has the annoyance of needing to restart the the terminal (or open a new one) for changes to take effect, but works well other than that.

Re: Environment variables are a legacy mess: Let's dive deep into them

#14

Post by amelius »

formerly_proven wrote: post #10
amelius wrote: post #8

Another legacy mess: Argument list too long It's absolutely crazy that this isn't a dynamically resizable vector.

It is, there’s just a limit set by the kernel for the number of pages the command line as a whole can occupy or something like that.

No, it's still an artificial limit, even if you can change it (usually after your command has failed).

Re: Environment variables are a legacy mess: Let's dive deep into them

#15

Post by wmf »

simonask wrote: post #4

Interesting read. Another interesting fact is that `setenv()` is fundamentally broken on POSIX, and should essentially never be called in library code. In application code, it should be called only in the absence of any alternative, and certainly before any threads have started. The reason is that `getenv()` hands out raw pointers to the variables, so overwriting a variable using `setenv()` is impossible to guard aga…

AFAIK Solaris solved that problem but Linux refuses to copy their solution.

Re: Environment variables are a legacy mess: Let's dive deep into them

#16

Post by cedws »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

Linux security model is pretty broken without namespaces. systemd has some bells and whistles that help but if you want something better than environment variables you're naturally going to reach for cgroups.

Re: Environment variables are a legacy mess: Let's dive deep into them

#17

Post by rsyring »

robertlagrant wrote: post #7
rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

> On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. This is a very good point I'd never realised! I'm not sure how you get around it, though, as if that program can even find a credential and decrypt a file, i…

I added a note to my original post about how 1Password's cli tool work. Access to the binary doesn't mean automatic access to any authorized session. I think that's a good start. In my case, I have it tied into my fingerprint reader, so if something want's access to a secret using `op` I get a prompt to authorize. If I haven't just called `op` myself, I know it's a suspect request.

Re: Environment variables are a legacy mess: Let's dive deep into them

#18

Post by bjourne »

We're almost rid of dotfiles in $HOME. Can we please also get rid of the abuse of environment variables for configuration? There is no reason your program needs to muck up the environment table of every process by defining MY_PROGRAM_API_KEY instead of taking a command line argument or reading a configuration file. It's not "secure" just because it's not on the command line. And it will mess up for users because it's nigh impossible to ensure you have the same environment variables over all login types. The variable might be there when you run locally, but not in an ssh session or cron. Some ephemeral configuration such as LD_LIBRARY_PATH and PWD is difficult to handle without environment variables, but those are rare exceptions and not the norm.

Contribute to a clean environment! Don't use environment variables for configuration!

Re: Environment variables are a legacy mess: Let's dive deep into them

#19

Post by mhitza »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

> Any good solutions for passing secrets around that don't involve environment variables or regular plain text files?

memfd_secret comes to mind https://man7.org/linux/man-pages/man2/memfd_secret.2.html

I haven't seen much language support for it, though. On one part maybe because it's Linux only.

People that write in Rust (and maybe Go, depends how easy FFI is) should give it a try.

I wanted for a time to get some support for it in PHP, since wrapping a C function should be easy, but the thought of having to also modify php-fpm put a dent in that. I can't and don't want to hack on C code.

In practice it'd be great if the process manager spawn children after opening a secret file descriptor, and pass those on. Not in visible memory, not in /proc/*/environ

Re: Environment variables are a legacy mess: Let's dive deep into them

#20

Post by [deleted] »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

[deleted]
Post reply on HN