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

41–50 of 194 posts

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

#41

Post by llimllib »

mhitza wrote: post #19
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 s…

For go, it's available in /x/sys/unix: https://pkg.go.dev/golang.org/x/sys/unix#MemfdSecret

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

#43

Post by zdc1 »

bbkane wrote: post #11
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?

Point to a file? E.g. `CONFIG_PATH=/etc/myapp/config.ini /opt/myapp`

That being said, I still use env vars and don't plan on stopping. I just haven't (yet?) seen any exploits or threat models relating to it that would keep me up at night.

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

#44

Post by motorest »

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…

> Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice:

I think environment variables are recommended to pass configuration parameters, and also secrets, in containerized applications managed by container orchestration systems.

By design, other processes cannot inspect what environment variables are running in a container.

Also, environment variables are passed to child processes because, by design, the goal is to run child processes in the same environment (i.e., same values) as the parent process, or with minor tweaks. Also, the process that spawns child processes is the one responsible for set it's environment variables, which means it already has at least read access to those secrets.

All in all I think all your concerns are based on specious reasoning, but I'll gladly discuss them in finer detail.

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

#45

Post by stackskipton »

SRE/Sysadmin/DevOps/Whatever here, while blog didn't talk about doing anything difficult but setting ENVVAR standards, I will point out all replacements are just as frustrating especially when talking about secrets.

Anything involving vaults where Application reaches out to specific secret vault like Hashicorp Vault/OpenBao/Secrets Manager quickly becomes massive vendor lock in where replacement is very difficult due to library replacement and makes vault uptime extremely important. This puts Ops in extremely difficult place when it becomes time to upgrade or do maintenance.

Config files have problem of you have secrets, how do you get them into config file since config files are generally kept in public systems? Most of the time it's some form of either "Template replacement by privileged system before handing it to application" or "Entire Config File gets loaded into secret vault and passed into application". Templating can be error prone and loading entire config files into secret manager is frustrating as well since someone could screw up the load.

Speaking of config files, since most systems are running containers, and unless you are at Ops discipline company, these config files are never in the right place, it becomes error prone for Ops to screw up the mounting. Also, whatever format you use, JSON/YAML/TOML is ripe for some weird config file bug to emerge like Norway problem in YAML.

Getting secrets from Kubernetes Secrets API I've seen done but lock in again. I'd strongly not recommend this approach unless you are designing a Kubernetes operator or other such type system.

I will say I've seen Subprocess thing bite people but I've seen less and less subprocess generation these days. Most teams go with message bus type system instead of sub processing since it's more robust and allows independent scaling.

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

#46

Post by jhallenworld »

Eh, they are just more command line arguments, ones that go on the left side of the command instead of the right. I guess an alternative is something the Windows registry, but I'm not seeing that as a great improvement since it's less direct.

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

#47

Post by maccard »

zdc1 wrote: post #43
bbkane wrote: post #11

Earlier quoted context omitted.

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

Point to a file? E.g. `CONFIG_PATH=/etc/myapp/config.ini /opt/myapp` That being said, I still use env vars and don't plan on stopping. I just haven't (yet?) seen any exploits or threat models relating to it that would keep me up at night.

How do you get that file?

I also use env vars.

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

#48

Post by sureglymop »

nrds wrote: post #35
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…

I think it's worth specifically calling out that the right way to set environment variables is in execve() only, as communication across an exec() is the precise niche for which they are the right tool.

Why are they the right tool for that instead of passing data with program args or another way of IPC?

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

#49

Post by monocasa »

ori_b wrote: post #27
wmf wrote: post #15

Earlier quoted context omitted.

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

Their solution was that setenv leaks memory rather than overwriting in place. FreeBSD does the same. See here for discussion: https://freebsd-current.freebsd.narkive.com/NwqZQDWm/fix-for...

Sure. But practically the amount you leak is infinitesimal.

For a lot of applications that's the right call given the rest of the posix semantics you're constrained to and the kinds and frequency of data you pass via env vars.

Post reply on HN