alex@xios.UUCP (Alex B Laney) (10/23/86)
References:
Sender:
Reply-To: alex@xios.UUCP (Alex B Laney)
Followup-To:
Distribution: na
Organization: Xios systems corp, The Renaissance(tm) people
Keywords: sh, test, bug
I have seen this bug in SVR2 systems (see below). My question is --
Has this been fixed in SVR3?
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 ) but definitely not for test -x working in this way.
The other test ops appear to work correctly.
This can't be a feature!
Script started on Thu Oct 23 09:31:01 1986
# cat mk
:
echo hello
# ls -l mk
-rw-r--r-- 1 root root 13 Oct 23 09:30 mk
# test -x mk && echo yes
yes
# chmod 000 mk
# test -x mk && echo yes
yes
# test -r mk && echo yes
yes
# test -w mk && echo yes
yes
# mk
mk: cannot execute
# chmod 700 mk
# mk
hello
# chmod 000 mk
# test -x mk
# test -x mk && echo yes
yes
script done on Thu Oct 23 09:33:12 1986
( The "script" command comes with CT machines. )
I do some work with shell scripts for overnight backups and such, and I run
into this because I would have liked to used the execute permission as a way
for configuration at a site.
--
- + - + -
Alex Laney, Xios Systems Corp, 105-1600 Carling Av, Ottawa (613)725-5411x402
utzoo -
> !dciem
allegra!ihnp4!utcsri -- > nrcaer!xios!lib!alex
ucbvax!hplabs -- /
> !seismo!hadron!netex!prcrs/
decvax --guy@sun.UUCP (10/27/86)
> 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@sun.com (or guy@sun.arpa)
rml@hpfcdc.HP.COM (Bob Lenk) (10/28/86)
> This is a difficult call. "test" solves it in the most straightforward > fashion, by just reporting the results of the "access" system call. I agree that the implementation of test(1) is reasonable. I think that the behavior of access(2) should be considered a bug. When checking for execute permission on a non-directory (or an ordinary file, execute permission on other types is a don't care), it should use the same rules as exec, requiring at least one execute bit to be set. I know of no advantage to the current behavior (other than making the kernel code slightly simpler). The IEEE P1003 working group has recently decided to require this behavior, despite the fact that most current implementations don't work this way. Bob Lenk {hplabs, ihnp4}!hpfcla!rml