On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote: > Quoting Andreas Dilger (adilger@xxxxxxxxxxxxx): > > One of the important use cases I can see today is the ability to > > split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine > > grained attributes. > > Sounds plausible, though it suffers from both making capabilities far > more cumbersome (i.e. finding the right capability for what you wanted > to do) and backward compatibility. Perhaps at that point we should > introduce security.capabilityv2 xattrs. A binary can then carry > security.capability=CAP_SYS_ADMIN=p, and > security.capabilityv2=cap_may_clone_mntns=p. Well, the overhead of each EA is non-trivial (16 bytes/EA) for storing 12 bytes worth of data, so it is probably just better to keep extending the original capability fields as was in the proposal. > > What we definitely do NOT want to happen is an application that needs > > priviledged access (e.g. e2fsck, mount) to stop running because the > > new capabilities _would_ have been granted by the new kernel and are > > not by the old kernel and STRICTXATTR is used. > > > > To me it would seem that having extra capabilities on an old kernel > > is relatively harmless if the old kernel doesn't know what they are. > > It's like having a key to a door that you don't know where it is. > > If we ditch the STRICTXATTR option do the semantics seem sane to you? Seems reasonable. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
