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

131–140 of 194 posts

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

#131

Post by darrenf »

fullstop wrote: post #76
sureglymop wrote: post #48

Earlier quoted context omitted.

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

Program args can be seen with tools like 'ps', so passing credentials that way is a poor choice.

FWIW, environment variables (edit: of your own processes) can also be seen with `ps`.

     ps wwwex | grep [w]wwex
      31109 pts/0    R+     0:00 ps wwwex GDM_LANG=en_GB.utf8 STARSHIP_SHELL=fish GDMSESSION=xfce STARSHIP_SESSION_KEY=2904922223926273 XDG_CURRENT_DESKTOP=XFCE LC_NUMERIC=en_GB.UTF-8 TERMINFO=/usr/share/terminfo LC_MONETARY=en_GB.UTF-8 SHELL=/bin/fish LC_ADDRESS=en_GB.UTF-8 ... many, many more ...

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

#132

Post by fullstop »

darrenf wrote: post #131
fullstop wrote: post #76

Earlier quoted context omitted.

Program args can be seen with tools like 'ps', so passing credentials that way is a poor choice.

FWIW, environment variables (edit: of your own processes) can also be seen with `ps`. ps wwwex | grep [w]wwex 31109 pts/0 R+ 0:00 ps wwwex GDM_LANG=en_GB.utf8 STARSHIP_SHELL=fish GDMSESSION=xfce STARSHIP_SESSION_KEY=2904922223926273 XDG_CURRENT_DESKTOP=XFCE LC_NUMERIC=en_GB.UTF-8 TERMINFO=/usr/share/terminfo LC_MONETARY=en_GB.UTF-8 SHELL=/bin/fish LC_ADDRESS=en_GB.UTF-8 ... many, many more ...

Right, you can see your own environment variables. Root can see your environment variables. Another user can not.

edit: submitted before I saw your edit. :-)

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

#134

Post by nrvn »

One of the worst things about Environment variables among others discussed here is the implicit and opaque nature of them. Majority of applications rely on them in the *nix world. Even if more explicit and obvious ways of configuration files or remote services (consul/etcd, et al.) and command line arguments are supported env vars are traditionally supported as well.

But as mentioned in the article it is just a global hashmap that can be cloned and extended for child processes. Maybe in 1979 it was a good design decision. Today it sometimes hurts.

For example, kubernetes by default literally pollutes the container’s environment with so-called service links. And you will have fun time debugging a broken application if any of those “default” env vars conflict with the env vars that your app might expect to see.

https://kubernetes.io/docs/tutorials/services/connect-applic...

They are ubiquitous and we are living in the world of neo-conservatism in IT where legacy corner cuts are treated as a standard and never challenged (hello /bin, /usr/bin, /lib, /usr/lib)[0]

[0] - https://askubuntu.com/a/135679

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

#136

Post by akvadrako »

bjourne wrote: post #83
1718627440 wrote: post #29

Earlier quoted context omitted.

This problem is also removed by just not exporting the variables. Also you can just pass an envp to execvE.

"MY_APP_SECRET_KEY=bla myapp" hardly accomplishes anything substantial over "myapp --secret-key=blah" It's just a less robust and less well-supported command-line interface. It's not supported by most gui launchers, PowerShell, nor many cron implementations, for example.

The command line can be read by any user on the host (with `ps auxww` for example) while the environment cannot.

You should never pass secrets on the command line.

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

#137

Post by stackskipton »

1718627440 wrote: post #124
stackskipton wrote: post #119

Earlier quoted context omitted.

My initial Ops gut feeling says "This is as lock in and error prone as Application Vault Libraries" but if Dev wanted to propose this, I'd be willing to see it in real operation.

It isn't lock in, because all the application depends on is that it gets a string it can pass to exec/the shell and then reads all data from stdout until EOF as the secret.

Sure, but let's say you have 5 secrets to get or maybe the new vault CLI does not support just stdout printing but prints JSON only.

I still think this is worse than config file/Env Vars.

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

#138

Post by bbkane »

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.

Is that file more secure than the environment variables it's replacing? On Linux I think you can secure it to just your service with SELinux. Not sure about Windows

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

#139

Post by monocasa »

cbsmith wrote: post #61
monocasa wrote: post #49

Earlier quoted context omitted.

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.

An infinitesimal leak becomes a problem if it is done an infinite number of times... execve seems like the preferable choice on a lot of grounds.

Which is why I said

> frequency of data

Practically, if you're moving enough data through setenv that the memory leaked versus the steady state fluctuation of the program is at all visible, you've got much bigger problems.

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

#140

Post by [deleted] »

stackskipton wrote: post #45

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…

[deleted]
Post reply on HN