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

61–70 of 194 posts

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

#61

Post by cbsmith »

monocasa wrote: post #49
ori_b wrote: post #27

Earlier quoted context omitted.

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.

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.

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

#62

Post by 1718627440 »

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…

You can have a command setting that is invoked to get the string. This way you don't have vendor login, but also don't need a separate template step.

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

#63

Post by stackskipton »

jppittma wrote: post #52
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…

How is the kubernetes secret API lock in? Genuinely wondering - were you trying to use that deployment yaml for something other than a kubernetes deployment? For most applications, you should be mounting the secret on your application, then you can inject it as either an environment variable or a json file that your application reads in an environment agnostic way. Then, on the backend, you can configure etcd to use…

Because you can't run the container, even for development outside Kubernetes.

Yes, you can mount Secrets as Volumes or Env Var in Kubernetes which is fine but I'm not talking about "How you get env var/secret" but "Methods of dealing with config."

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

#64

Post by petre »

zdragnar wrote: post #22
the__alchemist wrote: post #13

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) f…

> but the usual procedures you find online stops working once you reboot (or close the terminal I think?) The environment isn't persistent between sessions. That means you need to make the change in a way that runs on every new session (login or new terminal window). Depending on how your system is configured: .bash_profile gets run once on every login .bashrc gets run once on every non-login new session (i.e. a new…

> Conceivably, it's possible to write a GUI tool that reads your .bashrc file

What's wrong with an envfile or envdir? The envdir is kind of annoying but at least you can set permissions on the files inside it.

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

#66

Post by NekkoDroid »

the__alchemist wrote: post #13

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) f…

On systemd systems you can just either set KEY=VALUE pairs in `/etc/environment` or any file in `/etc/environment.d/` (and technically a few other places [0]). In theory it should be relatively easy to write a GUI for it by manually parsing the files.

The application restarting part can't really be fixed, since environment variables aren't ever injected to a running process and can only be changed by the process itself (terms and conditions may apply) and even changes during runtime could be ignored since the program itself may have cached some already computed value based on the variable.

[0]: https://www.freedesktop.org/software/systemd/man/latest/envi...

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

#67

Post by rustyminnow »

motorest wrote: post #44
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…

I think in the context of containers you're right, there's a level of isolation and secrets are probably fine. But I think under other contexts that lack that isolation (e.g. bare-metal processes, local dev tooling) there are extra concerns.

(inb4: container env-vars are isolated from other containers, not from processes on the host system)

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

#68

Post by stackskipton »

1718627440 wrote: post #62
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…

You can have a command setting that is invoked to get the string. This way you don't have vendor login, but also don't need a separate template step.

You still need to present that to Application.

So Command Line leaks worse than Env Var.

Config file, see original post for problems.

Env Var, see blog for problems.

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

#69

Post by 1718627440 »

cedws wrote: post #16
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.

Linux/Unix security model is that different actors are represented by different OS users. When you don't do that, it's already like inviting the burglars in your living room.

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

#70

Post by peter_d_sherman »

>"Wow, I really enjoyed writing this… …and I hope it wasn’t a boring read."

No, it was very interesting actually!

An excellent deep-dive into the murky area of Unix/Linux environment variables, how they are set, how they are passed, what's really going on behind the scenes.

Basically a must-read for any present or future OS designer...

Observation (if I might!) -- environment variables are to programs (especially chains of programs, parent processes, sub processes and sub-sub processes, etc.) what parameters are to functions -- and/or what command-line parameters are... they're sort of like global variables that get passed around a lot...

They also can influence program behavior -- and thus the determinism of a program -- and thus the determinism of a chain of programs...

Phrased another way -- software that works on one developer's machine might not work on another developer's machine and/or in a production environment because one crucial environment variable was either set or not set, or set to the wrong value...

(NixOS seems to understand this pretty well... that "hermetically sealing" or closing or "performing a closure around" (that's probably slightly the wrong language/terminology in "Nix-speak" but bear with me!) a software environment, including the environment variables is the way to create deterministic software builds that run on any machine... but here I'm digressing...)

But my main point: I complete agree with the article's author -- environment variables are a legacy mess!

Although, if we think about it, environment variables (if we broaden the definition) are a sub-pattern of anything that affects the state of an individual machine or runtime environment -- in other words, things such as the Windows Registry, at least the global aspects of it -- are also in the same category.

Future OS's, when they offer environments for programs or chains of programs to run -- should be completely containerized -- that is, the view of the system -- what data/settings/environment variables/registry variables/files/syscalls/global variables it has access to -- should be completely determinable by the user, completely logabble, completely transparent, and completely able to be compared, one environment to another.

In this way, software that either a) fails to work at all b) works in a non-deterministic way -- can be more easily debugged/diagnosed/fixed (I'm looking at you, future AI's that will assist humans in doing this!) -- then if all of that information is in various different places, broken, and/or opaque...

To reiterate:

>"Wow, I really enjoyed writing this… …and I hope it wasn’t a boring read."

No, I really enjoyed reading it(!), it's a brilliant article, and thank you for writing it! :-)

Upvoted and favorited!

Post reply on HN