Bourne Shell Bug ( test ops )

[guy at sun.UUCP]

> Some background on this bug. I was logged in as root. ( It is not a bug
> for a regular user.) I have seen this on 3b2's, Ncr Towers, CT
> MightyFrames. I think that a case could be made for the test -r and test
> -w, ( because it is root )

In fact, a case can NOT really be made for having "test -r" or "test -w"
fail for "root" just because the permission bits don't permit access.  If
you want to test the permission bits, do an "ls", capture the output, and
scan it.  The "-r" and "-w" flags, according to the S5 manual, test whether
the file is "readable" or "writable"; the permission bits don't control
whether "root" can read or write the file or not.

> but definitely not for test -x working in this way.
> The other test ops appear to work correctly. 
> 
> This can't be a feature!

I would not say that.  Consider the following:

Script started on Sun Oct 26 14:07:28 1986
gorodish# mkdir mk
gorodish# chmod -x mk
gorodish# ls -ld mk
drw-r--r--  2 root           24 Oct 26 14:07 mk
gorodish# test -x mk && echo yes
yes
gorodish# chmod 0 mk
gorodish# test -x mk && echo yes
yes
gorodish# cd mk

The question now is "what is the definition of 'executable'?"  For a
directory, it means "searchable and 'cd'-to-able"; the fact that "execute"
permission was not explicitly granted to root is irrelevant for "cd" or for
references to files inside that directory.

However, the "exec" call will not succeed unless 1) you have "execute"
access, as indicated by the kernel's "access" routine - this permits root to
have "execute" access on all files, 2) the file is a plain file, and 3) the
file has at least one of its "execute" permission bits set.  The third test
was added so that "root" would get execute access despite any attempts to
explicitly deny them, *but* it would not get execute access to files not
intended to be executable.  (Otherwise, if there were a non-executable file
named "cat" in some directory searched by root's PATH, and that directory
occurred in the path before "/bin", all sorts of fun would ensue.)

This is a difficult call.  "test" solves it in the most straightforward
fashion, by just reporting the results of the "access" system call.  (Note
that this means any "test command" in a shell script executed by a set-UID
process will indicate whether the *real* user has the permissions in
question for the file being tested, not whether the *effective* user has
those permissions.  If, for example, you have some set-UID program using
"execvp" or "system" or whatever to run a shell script, this will happen.)
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)