On 2014-09-26 07:30, Drake Wilson wrote:
On 26/09/14 07:06, Mailing Lists (???) wrote:
Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make that much of a difference. From what I've read, most of the problems come from CGI scripts which invoke bash, and ssh post-authentication.
Anything that uses system(), popen(), or other similar "invoke command (implicitly via /bin/sh)" functions can be affected by problems with whatever is installed as /bin/sh. Some daemon configurations have lines for hooks: "invoke shell command when <event> occurs", with information passed to the command by various means (parameters, environment variables, etc.). Some programs allow specification of I/O targets as pipes to or from shell commands.
There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions how bash still imports shell functions from environment variables with magic names, even when called as sh. The --posix option seems something of a joke.
dash has some of this as well (in particular, it interprets CDPATH) but not nearly as much, and it's much less likely to gain more in the future.
I would support a move to dash as sh, but it's not primarily for security per se but for general cleanliness: bash as sh does more to encourage the proliferation of "presumptive bashisms" and has much more potential for future breakage in central system areas. I believe this is more in line with Arch's "Simplicity" and "Code-correctness over convenience" principles than conflating the needs of interactive and whole-system-default shells for convenience's sake, especially if bash is a moving target regarding which features might be enabled that might interfere with global functionality.
I strongly agree with this. Programs that ask for sh should get sh, and programs that ask for bash should get bash.
Programs that ask for bash and use bashisms are already broken for the Ubuntu family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed upstream*!
I also remember having to port some scripts from BSD to Arch and seeing how they broke on bash because bash has non-sh behaviours.
Bash is not sh, and should not be treated as such. I've no issue with having bash in my system and that scripts with the proper shebang use it.
I would not support a move of the _packaging_ system to another sh, because that's explicitly documented to use bash as its main scripting language and relies on its extended features, and the potential complications are better contained. I don't think that's relevant unless the current packaging system assumes that bash can be invoked as sh.
The case of interactive SSH is separate, because that depends on the user's interactive shell, not sh. The case of machine SSH in which the target account's shell is sh falls loosely into the program-program interoperation category.
On my own desktop system, when I realized sh was bash recently I immediately relinked it to dash and intend to keep it that way as long as I reasonably can (I assume some things may break, in the current state; I'm willing to deal with that on my own for now).
---> Drake Wilson