[...]
> > hm? this is really part of the 'executable' proper, _not_ of the
> > filesystem. capabilities are inherently associated with binary executable
> > code. There is no point in allocating capabilities bimask for say a news
> > spool article file ...
Yes, but they *can't* be part of the binary executable itself: It would be
just way too easy to fake them. The OS has to get whatever info it needs
for setting special capabilities from some trusted source, and this can't
be the file contents itself ==> It has to come from the FS. And I just
don't like ideas like "If it's SUID, check in the file for capabilities".
Just too easy to screw up either way (one is certainly more than enough, as
this list shows ;)
> I retract my previous position. You are probably correct. This somewhat
> flys in the face of the traditional UNIX model of having all
> protection-related information in the inode but the benefits may outweigh
> that.
I hope you retract your retraction ;-)
> Some food for thought:
> 1. When selecting a method to encode the capabilities into the ELF binary,
> it should be a high priority to select something so that the information
> can easily be retrived, preferably by file(1).
No good. I can bring my own SUID root equivalent capable binaries from
home, or just edit some random copy of /bin/sh with emacs to fix it up.
> 2. How bad is it that we're limited to ELF? Is it important to allow
> things like capability-enhanced perl scripts, for instance.
> set[ug]id perl scripts are fairly common now.
Extremely bad. You would be a damned racist ;-)
> 3. Remember that unlike ext2-level checks there will be no way for the
> kernel to prevent the owner of the file from changing its capabilities.
Exactly.
> Obviously it would refuse to honor them for non-suid-root files but
> what about protecting from root? This works against the division-of-root
> concept of capabilities.
Yep, you've got back root with all its glory. The _only_ way out is to have
the permissions in a trusted place that not even root can subvert. This
means BTW that root can't write directly to disks, or change permissions on
devices...
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu