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:
> >
> > KUBERNETES_RELEASE_URL="${KUBERNETES_RELEASE_URL:-https://dl.k8s.io}";
> >
> > 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}
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
$ echo $FILE
/etc/passwd
$
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
$
and:
$ grep root ${FILE:=/etc/passwd}
/etc/passwd:root:x:0:0:root:/root:/bin/bash
/etc/passwd:operator:x:11:0:operator:/root:/sbin/nologin
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.
rday