Messages in this thread | | | Date | Tue, 20 Apr 1999 11:16:43 +1000 | From | Richard Gooch <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
tytso@mit.edu writes: > From: "Albert D. Cahalan" <acahalan@cs.uml.edu> > Date: Sat, 17 Apr 1999 20:15:22 -0400 (EDT) > > 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; 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.
Ted, this is simply false. I first suggested a solution to this problem on 3-APR-1999, and I've referred to it since then. It looks to me that you are the one who has not followed the discussion. I wrote:
> % ls -lF /usr/bin/lpq > -rwsr-xr-x 1 root root 83894 Apr 1 1999 /usr/bin/lpq* > % capshow /usr/bin/lpq > Grant: CAP_EUID, CAP_PRIV_SOCK > Deny: CAP_SOMETHING > Euid: 20 (lp) > [...] > > So, in other words, you have a capability that says "look in the > header for a UID and switch euid to that". So Albert can still have > his full compatibility with tar, uucp, cp, ar, NFS, isofs and > everything else.
Whether or not you think this is an ugly solution, it clearly shows that the problem you raised is easily solved. And it will work securely over NFS unlike the sticky bit. Whatever you may think, using NFS for privileged files has valid uses. My scheme gives the sysadmin the choice, at least. You would remove that choice.
> Therefore, using setuid root is insuficient. Q.E.D.
Obviously not Q.E.D.
Regards,
Richard....
- 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/
| |