Re: Detecting invocation as /bin/sh ?
Alexandre Ferrieux wrote: > Greg Wooledge wrote: > > Unfortunately, most people don't actually express an intent when they > > use #!/bin/sh. They just copy some code from a random script they found > > somewhere, without understanding what it means. > > That song reminds me of PHP. I was under the optimistic assumption > that bash, given its noble ancestry, was not exactly targeting the > same audience. The shell is part of the landscape. It has been around since the beginning. Although some try to avoid it others embrace it. It is not a matter of targeting an audience. It is simply the way things are. > > The number of scripts that use #!/bin/sh but then go on to use Bash > > syntax is higher than you might believe. Agreed. But those are not portable. And they are one of the reasons behind dash and the other targeted shells. > OK. Sh*t happens. Bozos write scripts. So what ? > A more interesting question IMO is: > > How many packaged init scripts / mission-critical daemons are > written by people that cannot be bothered to write #! /bin/bash > when they require bash ? Lots and lots and lots. When Debian converted from /bin/sh being bash over to it being dash there were many bugs found. The process of getting those instances cleaned up took a long time. Years. > > It's not a stretch of the imagination to suppose that someone has used > > exported functions in a #!/bin/sh script on a Linux box where /bin/sh > > is a symlink to bash. > > Except that script would instantly break if *dash* was installed, > instead of bash, as target of the sh symlink. So that beast would > already be extremely fragile. Agreed to both. Definitely fragile. But people do it just the same. Personally I would vote to have bash not support exported functions in /bin/sh mode. But as Chet has indicated the task of maintaining a stripped down shell is the target of dash and posh and others and not the target for bash. It would be duplicated effort if bash also targeted that too. So while bash might or might not do some of that it isn't really the project for it. Bob
Re: Detecting invocation as /bin/sh ?
On Tuesday, September 30, 2014 2:42:33 AM UTC+2, Chet Ramey wrote: > On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote: > > > > [bash -p] *does* disable that embarrassing nightmare of a misfeature that > > is function import: > > I guess if that's what you mean by "just the sh", then yes, it does. > That's a unique interpretation. You may deem this a peculiar interpretation, but it might be shared by the overwhelming crowd of those who never noticed (before last week) 1/ that bash was "powering" their decades-old init scripts and CGIs and 2/ that bash evalled something from the env. The consequence of all this might well be a switch. -Alex
Re: Detecting invocation as /bin/sh ?
On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote: > On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote: >> >>> Forget about posix mode then: bash -p (privileged) offers a lean-and-mean >>> variant which pretty much satisfies anybody needing "just sh". However, >>> there is no way to store an option in a symbolic link, so all distributions >>> doing "sh -> bash" are bound to perpetuate the danger (of >>> "eval-from-the-env"). So it would seem normal for some of them to move away >>> from bash as the default sh. >> >> Are we talking about the same thing? >> Privileged mode is intended for use when bash might run setuid (a bad idea >> in any case). It affects what bash will use from the environment -- yes, >> including shell functions -- and inhibits setting the euid to the ruid. >> It doesn't have any other effect. It certainly doesn't turn off any bash >> features. > > It *does* disable that embarrassing nightmare of a misfeature that is > function import: I guess if that's what you mean by "just the sh", then yes, it does. That's a unique interpretation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Detecting invocation as /bin/sh ?
On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
>
> > Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
> > variant which pretty much satisfies anybody needing "just sh". However,
> > there is no way to store an option in a symbolic link, so all distributions
> > doing "sh -> bash" are bound to perpetuate the danger (of
> > "eval-from-the-env"). So it would seem normal for some of them to move away
> > from bash as the default sh.
>
> Are we talking about the same thing?
> Privileged mode is intended for use when bash might run setuid (a bad idea
> in any case). It affects what bash will use from the environment -- yes,
> including shell functions -- and inhibits setting the euid to the ruid.
> It doesn't have any other effect. It certainly doesn't turn off any bash
> features.
It *does* disable that embarrassing nightmare of a misfeature that is function
import:
if (privmode == 0 && ... && STREQN ("() {", string, 4))
...
parse_and_execute(...)
So, from the perspective of a "just the sh, Ma'am" goal, it is a pretty good
contender. Regardless of the faith one can have in the recent patches, shunning
that 'parse_and_execute(environment)' altogether sounds orders of magnitude
safer.
-Alex
Re: Detecting invocation as /bin/sh ?
On 9/29/14, 5:46 PM, Alexandre Ferrieux wrote: > Forget about posix mode then: bash -p (privileged) offers a lean-and-mean > variant which pretty much satisfies anybody needing "just sh". However, there > is no way to store an option in a symbolic link, so all distributions doing > "sh -> bash" are bound to perpetuate the danger (of "eval-from-the-env"). So > it would seem normal for some of them to move away from bash as the default > sh. Are we talking about the same thing? Privileged mode is intended for use when bash might run setuid (a bad idea in any case). It affects what bash will use from the environment -- yes, including shell functions -- and inhibits setting the euid to the ruid. It doesn't have any other effect. It certainly doesn't turn off any bash features. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Detecting invocation as /bin/sh ?
On Monday, September 29, 2014 9:51:45 PM UTC+2, Chet Ramey wrote: > > > > So it seems the order is wrong. As a consequence, and this is confirmed by > > experience, the #!/bin/sh prefix behaves as featuristic bash. > > My suggestion then is to undo that mistake. > > Posix mode was never intended to turn bash into a shell that provides only > what Posix specifies and nothing more. It makes bash conform to Posix by > changing things where the default mode differs from what Posix specifies. > Posix allows this, and allows extensions, and every shell that claims > Posix conformance (except perhaps `posh') offers extensions beyond minimal > Posix features. Forget about posix mode then: bash -p (privileged) offers a lean-and-mean variant which pretty much satisfies anybody needing "just sh". However, there is no way to store an option in a symbolic link, so all distributions doing "sh -> bash" are bound to perpetuate the danger (of "eval-from-the-env"). So it would seem normal for some of them to move away from bash as the default sh. -Alex
Re: Detecting invocation as /bin/sh ?
On 9/26/14, 4:29 PM, Alexandre Ferrieux wrote:
> On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
>> Alexandre Ferrieux writes:
>>
>>> So, what about, in bash's initialization, detecting that we are invoked as
>>> "/bin/sh",
>>
>> It already does. See (bash) Bash POSIX Mode.
>
> Yes, it does do this detection, but too late for our concern, since things
> occur in the following order:
>
> (1) set_shell_name(argv[0]) => this detects "sh" and sets 'act_like_sh'
> (2) shell_initialize() => this decides to import funcs from env depending on
> flags like 'posixly_correct'
> (3) if (act_like_sh) ... sv_strict_posix ("POSIXLY_CORRECT")
>
> So it seems the order is wrong. As a consequence, and this is confirmed by
> experience, the #!/bin/sh prefix behaves as featuristic bash.
>
> My suggestion then is to undo that mistake.
Posix mode was never intended to turn bash into a shell that provides only
what Posix specifies and nothing more. It makes bash conform to Posix by
changing things where the default mode differs from what Posix specifies.
Posix allows this, and allows extensions, and every shell that claims
Posix conformance (except perhaps `posh') offers extensions beyond minimal
Posix features.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Detecting invocation as /bin/sh ?
On Friday, September 26, 2014 2:14:46 PM UTC+2, Greg Wooledge wrote: > On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote: > > > Of course, their intention is precisely expressed by the '#!/bin/sh' header > > Unfortunately, most people don't actually express an intent when they > use #!/bin/sh. They just copy some code from a random script they found > somewhere, without understanding what it means. That song reminds me of PHP. I was under the optimistic assumption that bash, given its noble ancestry, was not exactly targeting the same audience. > The number of scripts that use #!/bin/sh but then go on to use Bash > syntax is higher than you might believe. OK. Sh*t happens. Bozos write scripts. So what ? A more interesting question IMO is: How many packaged init scripts / mission-critical daemons are written by people that cannot be bothered to write #! /bin/bash when they require bash ? > It's not a stretch of the imagination to suppose that someone has used > exported functions in a #!/bin/sh script on a Linux box where /bin/sh > is a symlink to bash. Except that script would instantly break if *dash* was installed, instead of bash, as target of the sh symlink. So that beast would already be extremely fragile. -Alex
Re: Detecting invocation as /bin/sh ?
On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
> Alexandre Ferrieux writes:
>
> > So, what about, in bash's initialization, detecting that we are invoked as
> > "/bin/sh",
>
> It already does. See (bash) Bash POSIX Mode.
Yes, it does do this detection, but too late for our concern, since things
occur in the following order:
(1) set_shell_name(argv[0]) => this detects "sh" and sets 'act_like_sh'
(2) shell_initialize() => this decides to import funcs from env depending on
flags like 'posixly_correct'
(3) if (act_like_sh) ... sv_strict_posix ("POSIXLY_CORRECT")
So it seems the order is wrong. As a consequence, and this is confirmed by
experience, the #!/bin/sh prefix behaves as featuristic bash.
My suggestion then is to undo that mistake.
-Alex
Re: Detecting invocation as /bin/sh ?
On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote:
> Of course, their intention is precisely expressed by the '#!/bin/sh' header
Unfortunately, most people don't actually express an intent when they
use #!/bin/sh. They just copy some code from a random script they found
somewhere, without understanding what it means.
The number of scripts that use #!/bin/sh but then go on to use Bash
syntax is higher than you might believe. Whether exported functions are
in that toolset, I couldn't say for sure, but it's likely. Even in the
#bash channel on IRC we have often advocated constructs like this:
myfunc() { ...; }
export -f myfunc
find . -type f -exec bash -c 'for f; do myfunc "$f"; done' _ {} +
(This is in response to "Why can't I do find -exec myfunc", which is
something of a frequently asked question.)
It's not a stretch of the imagination to suppose that someone has used
exported functions in a #!/bin/sh script on a Linux box where /bin/sh
is a symlink to bash.
Re: Detecting invocation as /bin/sh ?
Alexandre Ferrieux writes: > So, what about, in bash's initialization, detecting that we are invoked as > "/bin/sh", It already does. See (bash) Bash POSIX Mode. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Detecting invocation as /bin/sh ?
Hello, In the wake of the exported func bug, as can be seen in the nearby thread "Issues with exported functions", many people are just now discovering a host of things that bash does, of course in a documented way, but that they never needed in the first place. Of course, their intention is precisely expressed by the '#!/bin/sh' header in scripts, but most major Unices today just have a symbolic link there (sh->bash). So, what about, in bash's initialization, detecting that we are invoked as "/bin/sh", and disabling all those bells and whistles (or behaving as bash -p, which is a close approximation) ? Note we already have something similar with the name "rbash" that triggers restricted mode: restricted_shell = shell_is_restricted (shell_name); So I'm merely proposing to do the same with privileged_mode (or a close cousin if its side effects are too strong): privileged_mode = shell_is_legacy_sh (shell_name); Reactions ? -Alex
