On 2014-09-26 11:27, Hugo Osvaldo Barrera wrote:
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.
If Bash's behavior doesn't comply with POSIX sh when called from the sh
symlink, that's a bug and should be reported upstream.
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
