Messages in this thread | | | Date | Thu, 30 Dec 1999 09:37:50 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: strace security <feature> |
| |
"Richard B. Johnson" <root@chaos.analogic.com>: >Now I see the rules have been changed so that if the EUID *or* the UID >are 0, the system calls are allowed to function as though the UID was 0. >If this corresponds to later POSIX rules, the committee should consider >the implications without regard to maintaining reverse compatibility.
As far as I can see, this hasn't changed in UNIX for the last 15 years. If a parent process is root (either EUID or UID) forks, the child process still has the same (EUID/UID) priveleges. If it execs another program, the child still has the same priveleges (that of the greatest privelege).
>Also, I think I have read (recently) that, for a program to function >suid-root, it must be owned by root and exist in a root-owned directory.
Not on any system I have access to (Sun, Cray, SGI, and Linux).
>This does not seem to be in current implementation, I can make a suid-root >program, put it in a directory owned by 200.200, and it still shows >the EUID as 0.
Normal activity. Membership in a directory cannot determine wether a parent directory is/is not root owned. Consider the case of a single disk system: a user may establish a hard link to /bin/passwd. Now: is the parent directory that the suid-root passwd program owned by root? There are now two parent directories - one is owned by root, one is not. Both are valid.
>... >The EUID should have remained at 100. > >It does comply with the rule about root ownership, but the directory >can be owned by anybody.
This is normal. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |