Re: caps in elf headers: use the sticky bit!

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 20 Apr 1999 11:16:43 +1000

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/