I gave up on environment variables long ago. Now my compilers read a dmd.conf file that is in the same directory as the compiler executable.
Environment variables are a legacy mess: Let's dive deep into them
31–40 of 194 posts
Re: Environment variables are a legacy mess: Let's dive deep into them
#32Earlier quoted context omitted.
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.
Yeah seems you're right, I thought namespaces came under the cgroups umbrella.
Re: Environment variables are a legacy mess: Let's dive deep into them
#33That was a hard to read font.
Huh... Guess it's what you're used to.
First thing that struck me about the site is how beautiful I found it. I even inspected the font: Iosevka Web, apparently.
Re: Environment variables are a legacy mess: Let's dive deep into them
#34...and people have to find special ways to set them. I didn't even know that pam_env existed until a recent security vulnerability announcement. It's never come to my attention before, I don't think I've ever seen it utilized. I've now made a runbook item to disable it. It's a shame that "configuration" includes undoing the fetishes and helpfulness [0][1] of others.
pam-config -d --env
[1] I'm at a stop sign. Some complete idiot is trying to turn left onto the street I'm leaving and waving me to turn left in front of them. Fuck no! I turn in front of you, somebody rearends you, you fly forward into me: my fault! You should be able to make this turn, if you can't go around the block! [2]
[2] I could go out of my way and turn right. Or I can just wait and see what happens.
Re: Environment variables are a legacy mess: Let's dive deep into them
#35Interesting 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.
Re: Environment variables are a legacy mess: Let's dive deep into them
#36Environment 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…
Not an answer, but I do wish there was a low level primitive and a corresponding high level language construct to pass around secrets.
Something like: my_secret = create_secret(value)
Then ideally it's an opaque value from that point on
Re: Environment variables are a legacy mess: Let's dive deep into them
#37Environment 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's namespaces are not a security mechanism. Please do not use them as one.
Re: Environment variables are a legacy mess: Let's dive deep into them
#38That was a hard to read font.
Change your browser settings. You can tell the browser what font you prefer to use, and set minimum font sizes. You can also turn off remote fonts, so that pages can only use fonts you already have. Then you can just uninstall any fonts you don’t like or that you cannot read easily.
Re: Environment variables are a legacy mess: Let's dive deep into them
#39Earlier quoted context omitted.
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's namespaces are not a security mechanism. Please do not use them as one.
I've said exactly the same thing on HN myself. However for this problem what do you suggest? Using namespaces is better than using no namespaces.
Re: Environment variables are a legacy mess: Let's dive deep into them
#40Environment 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…
I've never tried to use ptrace-read to read secrets from a running process's memory so I can't comment on that part.
I had always assumed getting secrets from a running process' memory was non-trivial and/or required root permissions but maybe that's a bad assumption.
However, reading a process' environment is as trivial as:
`cat /proc/123456/environ`
as long as it's ran by the same user. No ptrace-read required.