Messages in this thread | | | Date | Sat, 3 Apr 1999 09:59:56 +1000 | From | Richard Gooch <> | Subject | Re: ext3 to include capabilities? |
| |
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/
| |