[EMAIL PROTECTED] 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