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

21–30 of 194 posts

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

#21

Post by throwaway127482 »

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.

cgroups aren't relevant here, I think. Not sure if that was just a typo, since you did mention namespaces in the first sentence. PID and user namespaces in particular are relevant here.

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

#22

Post by zdragnar »

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 terminal window)

It's typical, if using these files, to do something like this:

    if [ -f ~/.bashrc ]; then
        source ~/.bashrc
    fi
in the .bash_profile file, putting most other things in .bashrc, such that you don't have to worry about the distinction.

If you're not even using bash or bash-likes at all, but instead something like Zsh, fish, etc you'll need to set things the way they want to be set there.

> They should add a simple env var GUI like Windows has that just works, and isn't terminal-specific

This doesn't exist in linux, because there isn't "one place" that all possible terminals draw from. Conceivably, it's possible to write a GUI tool that reads your .bashrc file, looks for anything that resembles a variable, parses the bash code to look for ways it is set, and then present a GUI tool that could update it in common cases, but... it's way easier to just write the change in a text editor.

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

#23

Post by jcelerier »

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…

Funny, as a primarily linux user the windows behaviour irks me to no end, it's the cause of so many recurrent problems on end-user machines with so many apps that pollute environment.. and then you wonder why something doesn't work and then it turns out that for some reason you're using $SOFTWARE from c:\Perl64\bin instead of its proper place

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

#24

Post by bjourne »

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…

If are like most users you have secrets stored in read-protected files in ~/.ssh. There's nothing wrong with that.

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

#25

Post by foofoo12 »

wmf wrote: post #15
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.

Link?

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

#27

Post by ori_b »

wmf wrote: post #15
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.

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...

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

#28

Post by Analemma_ »

wmf wrote: post #15
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.

IIRC the Solaris implementation of getenv()/setenv() leaks memory, because they want it to still be POSIX-compatible and the POSIX API has a "obey the spec, don't leak memory, be thread-safe -- pick 2" thing going on and you can't actually have a bug-free solution that keeps compatibility with decades of Unix applications.

Arguably that's less harmful than the thread-safety issues on Linux, but there's no perfect solution here as long as POSIX stays what it is.

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

#29

Post by 1718627440 »

bjourne wrote: post #18

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…

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

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

#30

Post by amluto »

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…

Since at least 2012, environment variables have been at least as secure as ordinary memory:

    commit b409e578d9a4ec95913e06d8fea2a33f1754ea69
    Author: Cong Wang 
    Date:   Thu May 31 16:26:17 2012 -0700
    
        proc: clean up /proc//environ handling
You can't read another process's environment unless you can ptrace-read the process, and if you can ptrace-read the process you know all its secrets anyway.

cmdline is a different story.

Post reply on HN