[lkml]   [1999]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: caps in elf headers: use the sticky bit!
On Sat, 10 Apr 1999, Daniel Taylor wrote:

> On Sat, 10 Apr 1999, David L. Parsley (lkml account) wrote:
> > Hi all,
> > Geez, instead of overloading the meaning of 'setuid 0', let's just
> > use the sticky bit! I.e., sticky bit==cap flag:
> >
> If the capabilities are present we should use them.
> It is _redundant_ and unnecessary to have seperate flags
> for the existence of capabilities and the capabilities
> themselves.

No, a flag to enable capabilities for the file; if you read the
documentation on the kernel site as I've posted twice, you'd see the
existence of 'CAP_SETFCAP'; the capability for setting capabilities. I
say you need this raised to set/unset this cap-enabling flag.

> In fact, I think that _all_ binaries should have capabilities
> specified.

Why? Most binaries don't need any caps to do their work.

> > - To set the cap flag, a user (process) needs CAP_SETFCAP raised, and the
> > kernel (besides the normal fs checks) validates the cap headers as well
> > for legality. (this also applies to creating files with this flag raised;
> > i.e., through a copy operation)
> So we have a capability (to set capabilities) assigned to the UID.
> WHAT did you think I have been talking about all this time?

Actually, I put (process) in parentheses to indicate that having this cap
raised is an attribute of the current process, not an attribute of the
user. This is what I'm trying to say here: there is no _permanent_
mapping of capabilities to uid's. That's not how they work. Please go
read the privs documentation at the kernel website.

> > - While the cap flag is set, the file is immutable, so the file owner
> > can't edit the file directly to raise caps.
> The file owner cannot set any caps he does not possess anyway
> so this is not a problem.

If the file owner can directly edit a file which has it's capabilities
stored in the elf headers, then they can set any flags they desire without
using any special capability utility. So the file must be immutable when
caps are enabled.

> > - A file that is both setuid root and capability enabled has only those
> > capabilities granted in conjuction w/ the headers; if it's only setuid
> > root, the kernel can (as a configurable option?) treat it as before and
> > raise all caps.
> >
> Right, but why should this just apply to root? I thought that we were
> trying to do away with the need for root on a production system
> here, and all of the ideas being presented still depend on
> direct action by root for all changes in capabilities.

Yes, we're trying to do away with the need for root; but to convert a
system over, you'll need to have a kernel around that supports both the
magic of 'setuid 0' and the new capelf stuff, so you can fire up and run
the system and give all your setuid root binaries the right capabilities.
Then you can compile your kernel without the compatibility option, and
viola! - root is just a user like any other. Note: you better make
'getty' and/or 'login' grant all the necessary privs in some fashion.

Just to reitterate: uid != cap set.

> Am I the only one here who sees a problem with this?!

Dan, I think you have some misconceptions about capabilities...

> > This can bring us _really_ close to true capabilities support,
> > while avoiding the ugly hack of also storing uid + suid bit in the elf
> > headers.
> >
> That would be, and is, an ugly hack.
> It is also, I'll type this slowly, completely unnecessary!
> Ownership of the file is stored in the filesystem.
> If the filesystem says the binary is SUID-joe, then it may
> not do anything that joe may not do were he logged in.

You're confusing normal filesystem rights with capabilities.

> Daniel Taylor [gotta get a .sig file one o' these days]

- --
David L. Parsley
Network Specialist
City of Salem Schools

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.096 / U:4.168 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site