Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: caps in elf headers: use the sticky bit! | Date | Mon, 19 Apr 1999 04:28:02 -0400 (EDT) |
| |
Theodore Y. Ts'o writes: > From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
>> Clearly you have missed a large chunk of the discussion. > > And again, clearly you have missed the discussion where it has been > pointed out repeatedly that this is insufficient;
Well, I tried to be polite... (granting you an excuse)
You claimed that the setuid-bit meant an executable would run as root. This is not true, as anyone following the discussion would know.
> a program may need to > be setuid "daemon" (or some other non-root UID), so that it has the > ability to access files owned by a particular uid, as well as have some > capabilities set. > > Therefore, using setuid root is insuficient. Q.E.D.
No, not "Q.E.D." at all. This is idiotic. All options have major flaws. That includes filesystem support, the sticky bit, PGP...
Let's look at the processes on a normal Linux system first.
$ ps -Nu root,albert,luser PID TTY TIME CMD $ ps -NU root,albert,luser PID TTY TIME CMD $
The daemons don't run as "albert" or "luser". They run as root. There are exceptions on some systems, but a root-only solution will cover the vast majority of daemons.
Being setuid to a non-root user is usually a stupid idea anyway. Not counting ext2-specific hacks, it gives the right to turn the original executable into a trojan. This is why games are not setuid to a "games" user for their score files.
Our choices include:
* Incompatible filesystem hacks * Insecure sticky bit hacks * Incomplete or ugly setuid-root hacks * Inconvenient VMS-like hacks * Inefficient PGP-based hacks
As I've said before, we don't have to choose one. We can let the admin choose zero or more hacks for each mounted filesystem. One only needs a way to indicate trust. For a vendor-supplied CD-ROM, that might be everything on the disk. Some people may trust anything owned by root.
Trust is an administrative policy decision. The trust mechanism is barely related to the purpose it is used for.
- 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/
| |