Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux idallen-oak 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27
15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 48
Release Status: release
Description:
In both BASH and DASH the shell variable $PWD is not always set
by the shell on start-up to be the actual absolute path to the
current directory. If PWD is passed in via the environment, it
is used *as-is* as long as it is an absolute path and whatever
directory it resolves to is the *same* as the current directory.
This means you can pass in some crazy /././ and /../../../
pathnames via PWD and the shell will use them as-is.
I know that PWD can contain symlinks, if set with the "cd"
command and "physical" is turned off. (And I see that "physical"
isn't even an option in DASH.) But nothing documents how /././
and /../../ can ever appear in PWD, so these things shouldn't
be allowed to enter PWD via the environment.
As shown below, you can pass in values of PWD that cannot be set
using the "cd" command inside the shell itself. The examples
below that are full of /././ and /../../ crap are especially
troubling, since there is no way to use the "cd" command to set
these values inside the shell, and the man page says that PWD
is set by the "cd" command, so having values in PWD that can't
be set using "cd" is wrong.
I think it a bug that /././ and /../../ pathnames passed in
via PWD are not cleaned up on shell start-up. You could make a
case that a PWD containing symlinks should be allowed in from
the environment, (unless -o physical) but surely not /././
and /../../ in pathnames? The shell should do the equivalent
of "cd ." to clean up PWD at start-up.
The man page doesn't say what happens with PWD if it is passed
in via the environment. If you're going to keep the current
behaviour, please document it, since the environment allows messy
values in PWD that are unlike anything the shell does with the
"cd" command. Not what I was expecting, at all.
As implemented, I now have to start every shell script that
uses $PWD before using "cd" with either 'cd "$(/bin/pwd)"' or
'set -o physical ; cd .' to get PWD into a usable state.
Repeat-By:
$ cat i.sh
#!/bin/bash -u
echo "$PWD"
$ unset PWD
$ printenv PWD
$ ./i.sh
/home/idallen
$ PWD=crap ./i.sh
/home/idallen
$ PWD=/./././././home/././././idallen/./././. ./i.sh
/./././././home/././././idallen/./././.
$ ln -s /home/idallen /tmp/foo
$ PWD=/tmp/foo ./i.sh
/tmp/foo
$ PWD=/../../../../tmp/foo ./i.sh
/../../../../tmp/foo
