Timeline for Safely define an environment variable
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 9, 2018 at 2:14 | vote | accept | CommunityBot | ||
| May 8, 2018 at 18:37 | answer | added | Marco | timeline score: 2 | |
| May 7, 2018 at 21:40 | comment | added | user6860 | @JohanMyréen, kicking myself: you are of course quite right about other processes having their own environments. I wasn't aware, though, that child processes inherit read-only variables as read-write: thanks for that piece of info. So, would your recommended approach be to mark all the existing environment variables as read-only at the start of the script, and if so, would you (or nxnev) like to write that up as an answer? | |
| May 7, 2018 at 19:22 | history | tweeted | twitter.com/StackUnix/status/993571707612028929 | ||
| May 7, 2018 at 19:17 | comment | added | Johan Myréen | @sampablokuper "because if the existing variable was defined by some other process, and that process needs to be able to overwrite it." Please note that each process has its own copy of the environment, changing the value of a variable does not change the value in the parent process. Also, the readonly attribute on an environment variable is not inherited by the child process, the inherited environment variables start as read-write. | |
| May 7, 2018 at 17:53 | comment | added | user6860 | @nxnev, I tagged this question with bash and gnu rather than with POSIX ;) POSIX-compliance would be nice, but is not crucial, as long as the solution would work in a GNU Bash script on most mainstream GNU/Linux distros. If you have a solution in mind, the best thing would probably be to post it and to note the ways in which it is not POSIX-compliant. Thanks :) | |
| May 7, 2018 at 17:45 | history | edited | user6860 | CC BY-SA 4.0 | added 396 characters in body |
| May 7, 2018 at 17:37 | comment | added | nxnev | Does the solution need to be POSIX-compliant or it is ok to use some non-standard extensions? | |
| May 7, 2018 at 16:55 | comment | added | user6860 | @StéphaneChazelas, "Do you only need to consider scalar variables that have been exported to the environment (or where already in the environment when the shell was invoked)?" At the moment, yes, that's my interest, and I would be happy to mark as correct an answer providing this, or confirming that safedef achieves it and can't readily be bettered. However, ... "Or any variable scalar or not (array, hash...), exported or not?" ... it would certainly be nice to have a general solution :) | |
| May 7, 2018 at 16:40 | history | edited | user6860 | CC BY-SA 4.0 | Clarify |
| May 7, 2018 at 16:21 | comment | added | user6860 | @thrig, the problem with marking existing variables as read-only is twofold. 1. the problem of detecting their existence at the relevant moment (which seems more fraught with potential race conditions and other complications than my safedef approach above); and 2. because if the existing variable was defined by some other process, and that process needs to be able to overwrite it, then my marking it as read-only might cause that other process to fail (and indeed to do so in a subtle and headache-inducing manner). | |
| May 7, 2018 at 16:08 | history | edited | user6860 | CC BY-SA 4.0 | Clarify |
| May 7, 2018 at 15:26 | comment | added | Stéphane Chazelas | Do you only need to consider scalar variables that have been exported to the environment (or where already in the environment when the shell was invoked)? Or any variable scalar or not (array, hash...), exported or not? | |
| May 7, 2018 at 15:24 | comment | added | thrig | why not mark things-not-to-be-changed as readonly ? | |
| May 7, 2018 at 15:13 | history | edited | user6860 | CC BY-SA 4.0 | added 39 characters in body |
| May 7, 2018 at 14:58 | history | asked | user6860 | CC BY-SA 4.0 |