5 ms·

Regardless of whether it's a hack, my broader question is: is it common in Linux to manipulate environment variables on the fly for a process or program? I pri

Regardless of whether it's a hack, my broader question is: is it common in Linux to manipulate environment variables on the fly for a process or program? I primarily use Windows, both as an end-user and an amateur programmer. From my experience, most programs on Windows don’t do this. If parameters are needed, they’re usually passed as arguments, while environment variables are used for more permanent settings, like %PATH%.

izacus 2y ago
Yes, the fact that the original article exists shows that it's common :)
johannes1234321 2y ago
PATH is a good example why steam does this: Steam is a program to launch a wide variety of other programs, which it doesn't fully control. Those programs (games) may do anything including launching further programs (utilities), so steam may set PATH so that the game finds those utilities. It can also be a way to pass license information or other configuration settings.
- Tobu 2y ago
  Looks like the Steam team moved to control spawning and do execvpe. I would like to see at least in-process environment modification discouraged. Rust is dealing with the issue by considering getenv unsafe when coming through C, but getting rid of the read side is much harder than the write side.
jpk 2y ago
One thing to note about command line arguments on Linux is, any user can typically inspect `/proc/{pid}/cmdline` and get the full command line used to start the process. So if you pass secrets like API keys, passwords, etc, via an argument, they're visible to the rest of the system. However, if you put secrets into the environment of the child process, only the user that owns the child process can inspect `/proc/{pid}/environ`.
- vbezhenar 2y ago
  https://man7.org/linux/man-pages/man5/proc.5.html#DESCRIPTION https://man7.org/linux/man-pages/man5/proc.5.html#DESCRIPTIO... One can use `hidepid` parameter when mounting procfs to hide cmdlines. I don't know why this is not implemented today by default in most distros. Probably history reasons.
  - jpk 2y ago
    My guess is it would break stuff like `ps x`, but ideally tools that use the procfs would gracefully degrade in cases like this?
sumtechguy 2y ago
It is decently common enough in unix. You are correct with my windows stuff it is fairly rare to set env vars to change the launching process. In the unix world though I have seen the pattern a decent number of times. With windows programs usually you see the pattern (not always) if it is ported from a unix system. Windows likes its ini/registry/cli items to do configuration. It doesnt mean the pattern can not be used in windows, I personally just have not seen it as much with native win32 apps. If you fire up something like 'git bash' you can see entire bash functions bound to env variables. I think it goes back to where windows came from. That environment space in DOS was not exactly huge (256 bytes at one point?). In unix it seems like it was much larger and expressive.

izacus 2y ago

Yes, the fact that the original article exists shows that it's common :)

johannes1234321 2y ago

PATH is a good example why steam does this: Steam is a program to launch a wide variety of other programs, which it doesn't fully control. Those programs (games) may do anything including launching further programs (utilities), so steam may set PATH so that the game finds those utilities. It can also be a way to pass license information or other configuration settings.

Tobu 2y ago
Looks like the Steam team moved to control spawning and do execvpe. I would like to see at least in-process environment modification discouraged. Rust is dealing with the issue by considering getenv unsafe when coming through C, but getting rid of the read side is much harder than the write side.

jpk 2y ago

One thing to note about command line arguments on Linux is, any user can typically inspect `/proc/{pid}/cmdline` and get the full command line used to start the process. So if you pass secrets like API keys, passwords, etc, via an argument, they're visible to the rest of the system. However, if you put secrets into the environment of the child process, only the user that owns the child process can inspect `/proc/{pid}/environ`.

vbezhenar 2y ago
https://man7.org/linux/man-pages/man5/proc.5.html#DESCRIPTION https://man7.org/linux/man-pages/man5/proc.5.html#DESCRIPTIO... One can use `hidepid` parameter when mounting procfs to hide cmdlines. I don't know why this is not implemented today by default in most distros. Probably history reasons.
- jpk 2y ago
  My guess is it would break stuff like `ps x`, but ideally tools that use the procfs would gracefully degrade in cases like this?

sumtechguy 2y ago

It is decently common enough in unix. You are correct with my windows stuff it is fairly rare to set env vars to change the launching process. In the unix world though I have seen the pattern a decent number of times. With windows programs usually you see the pattern (not always) if it is ported from a unix system. Windows likes its ini/registry/cli items to do configuration. It doesnt mean the pattern can not be used in windows, I personally just have not seen it as much with native win32 apps. If you fire up something like 'git bash' you can see entire bash functions bound to env variables. I think it goes back to where windows came from. That environment space in DOS was not exactly huge (256 bytes at one point?). In unix it seems like it was much larger and expressive.