Shell – Protected environment variables

environment-variablesposixshell

Are there names of environment variables that cannot be overwritten by the user/a call to setenv? As I understand from POSIX1.2008, any process may edit the environment block, but must avoid overwriting such vars as LANG etc.

Best Answer

The environment is a list of strings of the form var=value (by convention) that is passed as the 3^rd argument to the execve() system call.

That list is put somewhere on the stack of the process when it starts to execute the new command just like for the list of arguments (another list of strings passed as the second argument to execve()).

In programs using the libc (most), an initialisation code called before the main() function is invoked, makes those environment strings available as the environ array.

The libc also provides with putenv and setenv functions that can modify (a copy of) that list that the program received. That maintained, modified copy will then be passed to the next command executed by the process or any of its children via the execvp()/execl()/system()/popen()... functions of the libc (which themselves end up calling the execve() system call).

Now while when you build up a list of strings that you pass manually to the execve() system call, you may pass strings like foo (without a = character) or =bar (with an empty variable name), setenv won't let you do that (setenv("", "bar", 1) is rejected).

setenv("a=b", "c") will also be rejected. So the strings that will be defined by setenv will always be of the format x=y where x may not be empty.

That's about the only restriction (also applied by putenv). Well those being NUL terminated strings, of course the NUL character cannot appear in the variable name or value.

setenv("*", "x", 1), or setenv("\n\n", "", 1) are all OK as far as setenv() or the kernel are concerned. Now, whether you're going to be able to do anything useful with those is another matter.

Related Solutions

Exception of inheritance of environment variables

In the unix model, starting another program involves two primivites:

fork() creates an (almost) identical copy of the calling process. The new process is called the child process and the original process is called the parent process. The child process runs the same code as the original, has the same permissions, has the same environment, and receives a copy of the mutable data memory of the parent process. The most visible difference between the two processes is that they have different process IDs and different parent process IDs (the child's PPID is the parent's PID).
execve() replaces the code and data of the current process by code and data loaded from an executable file. This system call takes the new environment of the process as an argument.

Most high-level functions built around fork() and execve() pass the process's current environment to execve(). Thus, unless the process changes its own environment or calls execve() directly, the called program will inherit the calling program's environment.

Shells normally pass their environment to the programs they call. You can change the environment of a shell at any time by assigning a value to an environment variable (foo="some value"; you must call export foo if the variable isn't in the environment already), or remove a variable from the environment by unsetting it (unset foo). If you want to start an external program with different or additional environment variables, there is a shortcut syntax:

foo="some value" mycommand

is roughly equivalent to

(foo="some value"; export foo; exec mycommand)

(where the parentheses restrict the scope of the setting of foo).

Best Answer

Related Solutions

Exception of inheritance of environment variables

Related Question