Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
herbert@gondor.apana.org.au on Tue, May 01, 2001 at 07:30:14AM +1000
# Let's try this again
reopen 95430
severity 95430 critical
retitle 95430 [SECURITY] ash honors IFS in environment
quit
On Tue, May 01, 2001 at 07:30:14AM +1000, Herbert Xu wrote:
>
> > I have consulted the Single Unix Standard and can find only dubious
> > justification for this assertion. It never flat out says whether IFS
> > is to be set on entry to the shell or not. However, I note this
> > paragraph:
>
> It's wrong regardless of whether the shell sets it. The whole point of
> saving IFS is so that you can restore it to its original value, which can
> be whatever the previous user has set it to, including the case of it not
> being set at all. If your code can't handle that, then please don't save
> the value at all.
Uh, no it can't. I'm talking about self-contained shell scripts, not
functions. IFS does not inherit through the environment.
Self-contained scripts can count on its being set to
"<space><tab><newline>" when execution begins.
(tests) ... except that ash does honor IFS from the environment. You
realize that this is a gaping security hole, even if IFS is only used
to split the results of expansion? You realize that it is trivial to
break any shell script on the entire machine that way?
Both 0.3.8 and 0.3.7-x are affected by *that* bug, incidentally.
[...]
> > In any case, your change is a gratuitous divergence from the upstream
> > code and a deliberate breakage of consensus shell behavior. My script
> > functions correctly with every Bourne-descended shell I have access to
> > except ash 0.3.8-1. (In addition to bash, pdksh, and previous
> > versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
> > and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
> > Solaris.) Irrespective of what the standard says, you cannot
> > introduce changes into /bin/sh which make it behave differently from
> > every other shell out there. Especially if they have the potential to
> > break every shell script which uses some feature.
>
> I can understand how frustrating it is to have your scripts broken by
> this. But the fact remains that it's the scripts that are broken, not the
> shell.
>
> Are your functions supposed to be called by other scripts in general? If
> so, then it's particularly important to handle the case of an unset IFS.
You don't get it, do you?
What the standard says is IRRELEVANT. You cannot change consensus
shell behavior even if it is in direct conflict with the standard.
Find me ONE other implementation of a Bourne shell, which does not set
IFS to "<space><tab><newline>" on initialization, ignoring the value
in the environment, and which postdates 4.4BSD and SVR4, and I'll shut
up. The burden is on you to do this. I believe I have adequately
demonstrated what the proper behavior is.
zw
Reply to: