On Sun, 8 Apr 2018, Stephen M. Webb wrote:

> On 2018-04-08 04:21 AM, Robert P. J. Day wrote:

> >   and there's this near the top:
> >
> >
> > ok, that will admittedly set that variable to a value if it does not
> > already have a value, but i've always done that this way:
> >
> >   : ${VAR:=defaultvalue}
> What would happen if I ran the script with, say, VAR="&& rm -rf /" ?
> Consider that installer scripts are often meant to be run as root.

  that does not appear to be a problem.  behold:

  $ unset FILE
  $ grep root ${FILE:=/etc/passwd}
  $ echo $FILE

however, trying to sneak a "&&" in there won't have the effect you're
after, because i'm pretty sure the shell tokenizes based on && and ||
*way* before it does variable expansion, so that by the time that
variable assignment is done, that && construct cannot *possibly* be
interpreted as conditional command execution:

  $ FILE="/etc/passwd && echo hi there"
  $ echo $FILE
  /etc/passwd && echo hi there


  $ grep root ${FILE:=/etc/passwd}
  grep: &&: No such file or directory
  grep: echo: No such file or directory
  grep: hi: No such file or directory
  grep: there: No such file or directory

see? && and everything after it is simply treated as part of the
variable expansion.

  i would have been shocked if that construct had that obvious a
security hole, given how often i've seen it in shell scripts.

Linux mailing list

Reply via email to