Re: ext3 to include capabilities?
Richard Gooch (rgooch@atnf.csiro.au)
Sat, 3 Apr 1999 09:59:56 +1000
Stephen C. Tweedie writes:
> Hi,
>
> On Sat, 3 Apr 1999 08:23:04 +1000, Richard Gooch <rgooch@atnf.csiro.au>
> said:
>
> > There is a distinction between suid-root and suid-others. You can
> > still have your suid-lp binaries and also overload the meaning of
> > suid-root.
>
> > The headers would have a mask of capabilities to grant, which the
> > kernel reads if the binary is suid-root, and also a mask of
> > capabilities to deny, which is always read.
>
> > You can then have a suid-root binary with:
> > grant: CAP_EUID_ROOT
> > deny: ~CAP_EUID_ROOT
>
> > which gives you suid-root with no capabilities.
>
> That's just fine, but it misses the point.
>
> In a capabilities world, I would want named to be suid to a non-root
> user, so that I can make sure that only that user has write access
> to the secondary zone files, for example. I would _also_ want named
> to have the bind-to-privileged-socket capability. If capability
> granting is enabled by overloading suid-root, then I cannot grant
> capabilities at the same time as I suid to a non-root user.
Hm. I was going to agree with you, but then I thought a bit more:
% 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.
Problems?
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/