dash's test ("[") builtin uses stat() instead of access()

Binary package hint: dash

The -r and -w (and possibly -x) flags to the test (aka "[") builtin,
in other shells like bash, as well as the /usr/bin/[ from coreutils,
use the access() system call to determine whether you have the ability
to read or write a file. dash's test, however, uses the stat() system
call, and manually checks the permission bits against your uid. This can
cause incorrect results on filesystems where there are more (or fewer)
permission checks than just the UNIX mode, such as most networked
filesystems. For instance, I have tax forms in AFS with mode 666, but my home directory is only actually readable if you have my credentials. dash doesn't realize this:

kid-icarus:~ geofft$ ls -l Form1098t.pdf
-rw-rw-rw- 1 geofft 501 25423 2007-04-01 23:28 Form1098t.pdf
kid-icarus:~ geofft$ [ -r Form1098t.pdf ] && echo yes
yes
kid-icarus:~ geofft$ unlog
kid-icarus:~ geofft$ [ -r Form1098t.pdf ] && echo yes
kid-icarus:~ geofft$ /usr/bin/[ -r Form1098t.pdf ] && echo yes
kid-icarus:~ geofft$ dash -c '[ -r Form1098t.pdf ] && echo yes'
yes
kid-icarus:~ geofft$ cat Form1098t.pdf
cat: Form1098t.pdf: Permission denied

dash should be changed to use access() instead, which will still return the correct answer on a filesystem that uses UNIX modes solely, but will ALSO return the correct answer on a filesystem that does something different and has an appropriate implementation of access().

There are warnings in access's manpage about a TOCTOU attack if you attempt to secure something by taking advantage of access() checking real UID whereas open() checks effective UID. This is basically irrelevant for shells, since you never have setuid shell scripts (and I've never seen a setuid shell). Something like "sudo sh" will set both the real and effective UIDs to root.

(The example above used Jaunty, with dash 0.5.4-12ubuntu2.)