PWD not made canonical on shell start

[idallen]

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