> > It's a no-lose situation until you start using the new features to add
> > privileges which weren't there in the first place.
>
> That's not the common case, though - the first things that get converted
> to use capabilities will surely be the existing suid stuff, won't they?
>
> Are you suggesting that the whole system should break when you reboot to
> an old kernel?
Yep.
> A lot of people are going to want to remove the suid bit from existing
> executables and add capabilities. If that then breaks when they reboot
> to an old kernel, then we've done something blatantly wrong. Using the
> suid bit as a marker to show the presence of a 'capability header' seems
> like an ideal solution, because it provides backwards compatibility
> without any loss of security in relation to the _existing_ situation.
s/the suid bit/an ext2 inode flag/ and I'll be convinced. One of the nice
things about the current ELF loader is that it doesn't have to dig too
deeply in the executables.
> New capability-holding utilities that were never suid and should never
> be suid can just include that one-liner I gave above.
Cruft. Look at the subject - we're not talking about existing systems.
This is a new and probably incompatible filesystem.
Personally, I hope that ext3 won't bother with providing backwards
compatibility to old kernels, but rather will clear out old backwards
compatibility code, add the exciting new stuff (ACLs, capabilities) and
fix some things (bigger [ug]id_t, dev_t, (off_t?)). The rest is missing
the point, IMHO.
Matthew
- who went to the boat race on Saturday :(
-
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/