[arch-general] A good time to switch to dash as /bin/sh?

[Doug Newgard]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pubkey.asc
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20140926/a94f524a/attachment.ksh>