Inherit environment variables from PID 1 by reading /proc/1/environ | Hacker News Reader

environ

gist.github.com

36 pointschatmasta23 comments

Reminds me of the fun fact that on Linux env vars are not really key-value, but just a list of strings; it's just a convention by libc to parse them as key-value by splitting on =. If you don't care about compatibility you could hypothetically use any format you want for env

Some programs, like sshd and chromium, make use of this fact to change the process name as shown in procfs and ps. On Linux, every string that argv[] and envp[] point to are stored in one contiguous block of memory. Programs can change the name of the process by writing a new string starting at *argv[0] and overflowing into the *envp[] memory as needed. (Though the program needs to strdup() the environ[] entries beforehand since they initially point to envp[] strings.)

For example, chromium's implementation: https://source.chromium.org/chromium/chromium/src/+/refs/tag...

Interesting that procfs reads directly from userspace memory to answer queries from /proc/{pid}/cmdline. I wonder what happens if someone unmaps the memory containing those argv/envp strings?

I just gave it a try in gdb on a C program with an empty main(). The argv/envp data was in this range:

    7ffffffdd000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]

Running `call (int) munmap(0x7ffffffdd000, 0x22000)` in gdb did indeed unmap the stack... and the program segfaulted immediately afterwards. But while the process was still in the stopped state and before it finished crashing/exiting, /proc/<pid>/cmdline was a 0-byte file.

This seems similar to the way command like arguments work on windows.

On Linux, the system call für spawning a process uses a string array for them.

On windows, it's a single string. The string needs to be parsed by the application, making escape sequences in command line arguments implementation defined by the compiler/runtime/etc.

https://nullprogram.com/blog/2022/02/18/

Some examples are here: https://daviddeley.com/autohotkey/parameters/parameters.htm#...

> This seems similar to the way command like arguments work on windows.

The previous poster overstates things. Environment variables passed to the process by the kernel[1] are NUL-delimited, including a double-NUL (or zero-length pair) to terminate the list of name=value pairs. Neither is there any syntactical ambiguity, as within each NUL-terminated pair the first '=' character delimits the variable name from the value, regardless of whether there are subsequent '=' characters. So there's no real parsing of the name=value content, only locating each NUL character in turn as a C array is built up by the entry code. The only limitation is that neither names nor values can contain the NUL character, and names cannot contain a '=' character.

The process startup code uses the exact same logic for constructing argv as it does for constructing environ/envp as they're both passed by the kernel in the same manner, including the same NUL-delimited structure. In fact, they're written as one long, serial sequence to the stack, above or beneath (depending on stack direction) the initial stack frame setup for the entry point. And usually argv and environ/envp arrays simply hold pointers directly to this memory region, at least initially. On Linux /proc/$$/environ reads out this region, so it won't necessarily reflect a process' actual environment variables once a process starts changing them.

[1] For both Linux and, at least historically, the BSDs.

The point I was trying to get across is that environment doesn't need to be list of name=value pairs, it's just list of strings and you can put anything in there.

In theory, a POSIX layer in Windows will implement the exec() family of system calls.

The Windows (NT) kernel was built to conform to POSIX, although this functionality was removed, then reimplemented and expanded.

'Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP.'

https://en.m.wikipedia.org/wiki/Windows_NT#Major_features

IIRC, WSL1 was another such "personality". Disappointing that WSL2 dropped that in favor of what's basically a glorified VM; maybe that's just easier to do than maintaining a (presumably clean-room, given the need to comply with the GPLv2 if any actual Linux code was ever used) reimplementation of the Linux userspace ABI?

Well, it's a key-value data structure, serialized in the way you describe. You could say that a JSON object wasn't a key-value structure by the same logic. It's the same way for structures serialized in binary rather than text, like BSON objects.

You can think of a native dictionary as a declarative structure where each of the pairs "happen" simultaneously. A serialized structure is necessarily imperative because it must be an ordered series of bytes that are evaluated in sequence; it must be in order to be written to disk or sent across the network (with /proc being a sort of hybrid, IPC implemented as a virtual filesystem). So we generally need to convert our dictionaries into lists to serialize them.

You might think of something like sending an entire SQLite database as an exception to this rule, but there's an equivalent perspective that it is an example of the rule instead. Lists of key-value pairs and dictionaries of key-value pairs are duals of each other so you're free to take the interpretation you prefer.

afaik the linux kernel doesn't read environment variables, but it does write some: processes spawned by the kernel, such as init, modprobe, and request_key, start with some pre-defined environment variables, like HOME=/ TERM=linux PATH=/sbin:/usr/sbin:/bin:/usr/bin.

The author also has not realized that xargs -0 can transform null-delimited fields into space-delimited fields.

I believe the invocation could be:

  export $(xargs -0 echo < /proc/1/environ)

It could be dangerous to use echo in this way in some circumstances.

eh, that sounds like a bad idea, as vars can contain spaces as well. You can solve this with quoting, but it is tricky, it is much nicer (and safer in case of errors!) to ensure you don't need to do that.

Somehow, "$@" would have to be involved for safe processing. I will ponder it.

“echo” is the default action for xargs, so you don’t need to specify it.

This is a poor hack that will backfire for someone. The CI process set up a certain environment for a reason. It purged some variables, and possibly altered others.

I'm likely guessing right that if, for instance, you take the PATH from /proc/pid/1 and install that as your PATH, your CI process may run into trouble, like not being able to find needed utilities.

That you need superuser privileges to get at these variables should be a red flag.

They are not touching original CI process, they are only modifying their own SSH session.

And they want to run CI commands from manual SSH process, so taking PATH (and everything else) from the original CI process is exactly what they want -- this is all part of the game for SSH process to be a real "CI" runner.

Kind reminder that you probably want to use the hidepid argument to prevent any sensitive data leaking through environment or command line arguments in a production server. (Things like API keys, passwords, and so on). It is a typical bad assumption that the only thing that can read my command line is my process and the only my process children can read my env variables.

where do you set variables on pid1 ?

I dont fully get this use case yet..

It's pretty niche (and hacky). My use case is debugging CI runners by connecting to them via a reverse shell [0]. I want to manually run CI commands, but my reverse shell drops me into a new process without any of the same environment variables available to it that are made available by the CI platform to the runner. So I wanted a command I could paste to quickly inherit those environment variables and run the CI scripts that depend on them.

[0] https://github.com/milesrichardson/shonion

Docker.

Or the kernel command line

https://www.kernel.org/doc/html/v5.15/admin-guide/kernel-par...

parameters with ‘=’ go into init’s environment

i used this to restart a process and resume its states by storing just enough data from previous process.

Reply on news.ycombinator.com