On Wednesday 09 May 2007 17:04, Carlos E. R. wrote: > The Wednesday 2007-05-09 at 14:34 -0700, Randall R Schulz wrote: > ... > > > It would be very odd for the shell not to be executable, but since > > root can still execute files without there x bit (am I remembering > > that right?), > > Er... I dont think so... you can always execute a script that is not > marked executable by doing "sh scriptname"; this is true for root and > normals users, and it can be the bash shell, or any other > interpreter.
I remember what the exception was (and I confirmed it this time). For ordinary users, the permissions used to grant or deny any particular access attempt is fixed based on whether the file's UID matches that of the request process, the GID matches or neither of the above. In the first case, the owner bits are used, period. In the second case, only the group bits are used and in the last case, the "other" bits are used. But for root it's a bit more complicated. For read and write access, root simply always gets access. For directory scanning, again, root gets access even with no execute bits, assuming the target of the access is actually a directory. (Ordinary users need execute access to get the kernel to look up a file in a directory, even if they have read access and can see the names of entities within that directory--in fact, they don't need read access, if they have execute access and know the name of an entity in the directory, they can access it). But to execute a file, root needs an execute bit, but it may be in any of thethe three groups (owner, group or other). To wit: # id uid=0(root) gid=0(root) groups=0(root) # cp /bin/sh shell # chmod 444 shell # ll shell -r--r--r-- 1 root root 490716 May 9 17:24 shell* # ./shell -bash: ./shell: Permission denied # chmod 445 shell # ll shell -r--r--r-x 1 root root 490716 May 9 17:24 shell* According to the rules applied to ordinary users, this "shell" would not now be executable, but for root, any execute bit will do: # echo $$ 12019 # ./shell # # Now in a sub-shell: # echo $$ 10501 > ... > > > Carlos' guess about the file system holding /bin being mounted > > "noexec" is a good one. It seems like the most likely explanation. > > Actually, I was thinking of the partition holding the configure > script; for example, "/home". My fuzzy memory says I heard of that in > this very list some other time ;-) Ah. Even more probable. > -- > Cheers, > Carlos E. R. Randall Schulz -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
