-1

If I am correct, the environment of a process is an array of strings. The strings usually have the form "name=value", but not necessarily. I was wondering for what purposes the strings don't have the "name=value" form? Thanks.

Tim
  • 101,790
  • 2
    Can you give such an example? – Kusalananda Apr 16 '18 at 13:18
  • When your program calls execve() to execute a program, you can give whatever strings to the env argument. It is up to the program being invoked to interpret the environment strings. But I haven't seen such example. – Tim Apr 16 '18 at 13:20
  • Isn't name=value the shell's way of assigning values? Seeing a counterexample would clarify what you're asking about. – Jeff Schaller Apr 16 '18 at 13:26
  • I didn't mention shell. My post is asking for such cases and their purposes. – Tim Apr 16 '18 at 13:26
  • Is the commandline (and its parameters) not part of the environment of a program? They sure can be in another format. – Gerard H. Pille Apr 16 '18 at 14:42
  • 2
    I had an example of another different case, but the question has been closed. – JdeBP Apr 17 '18 at 18:25
  • @JdeBP Thanks. I'd appreciate reopen vote, and look forward to hearing your case either in comment or reply. Or you can add your case to my post, just separate it from my original post by a separator line. – Tim Apr 17 '18 at 18:51
  • 3
    I can't understand the close reason, this question perfectly clear to me. Reviewers: Please read the answer, then vote for reopen. – peterh Apr 17 '18 at 19:20

1 Answers1

3

I'm not aware of anything actually using or expecting environment strings that don't contain =. Those would typically be pathological cases.

GNU env or printenv will faithfully print them.

For some languages, those strings will be out of reach. For instance, if you call perl with a foo env string, it won't show in keys(%ENV), though perl would still pass it along to the commands it executes (unless you reset the whole %ENV hash).

So one could possibly use that to bypass some environment sanitizing (though proper environment sanitizing should start with an empty environment).

Some tools (like some shells) strip them from the environment they receive and don't pass them along to commands they execute, so in general it's not a good idea to rely on that.

Beside the =-less env strings, other pathological cases include env strings with duplicate variable name (like both foo=good and foo=bad passed in envp) which has already been seen as causing vulnerabilities (like CVE-2016-2381), and env strings like =foo (empty variable name; note that POSIX putenv()/getenv() can set/get that variable, but not setenv()).

Stéphane Chazelas
  • 544,893