| 1 | | There's a better approach to test if our shell is bash: to test whether it has BASH variable set (environmental OR internal -- vs. the getenv("BASH") test we currently have in master). The idea is to use [ -z "${BASH+x}" ] test as suggested here: [http://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash]. The patch below runs execl(mc_shell->path, mc_shell->path, "-c", "([ -z \"${BASH+x}\" ] && exit 1) || exit 0", (char *) NULL) in a child fork and has parent evaluate its exit code with waitpid(). I have tested this on different corner cases, like execl() failing, or program passed as SHELL not accepting the syntax. In theory, if SHELL is set as something intentionally malicious, execl() here can do bad things, but we will still do them, if shell is recognized as supported (and that's easy to achieve with a symlink), when we try to initialize it afterwards. |
| | 1 | There's a better approach to test if our shell is bash: to test whether it has BASH variable set (environmental OR internal -- vs. the getenv("BASH") test we currently have in master). The idea is to use [ -z "${BASH+x}" ] test as suggested here: [http://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash]. The patch below runs |
| | 2 | |
| | 3 | {{{ |
| | 4 | execl(mc_shell->path, mc_shell->path, "-c", "([ -z \"${BASH+x}\" ] && exit 1) || exit 0", (char *) NULL) |
| | 5 | }}} |
| | 6 | |
| | 7 | in a child fork and has parent evaluate its exit code with waitpid(). I have tested this on different corner cases, like execl() failing, or program passed as SHELL not accepting the syntax. In theory, if SHELL is set as something intentionally malicious, execl() here can do bad things, but we will still do them, if shell is recognized as supported (and that's easy to achieve with a symlink), when we try to initialize it afterwards. |
