Quoting Chris Wright ([EMAIL PROTECTED]): > * Casey Schaufler ([EMAIL PROTECTED]) wrote: > > --- Chris Wright <[EMAIL PROTECTED]> wrote: > > > > > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > > > Here is a new version of the 64-bit capability patches I was supposed > > > > to send last week I think. > > > > > > > > This patch could stand alone without the 64-bit caps, but should > > > > definately not be applied anywhere until it has been better > > > > reviewed. It is the alternative to the patch removing the > > > > capability type checking code. > > > > > > How likely is > 64?
My instinct is to say "not very", but only a fool would admit that publicly. > > If the Granularity Gremlins get loose the answer is 100%. > > DG/UX ended up with over 330. > > Yeah, I think a few systems ended up with > 64. > > > Fortunately the GGs have a playpen already in SELinux. > > I suggest that the capabilities maintainer be very stingy > > and refer anyone who's need isn't pretty obvious there. > > This means that the folks who want to divide CAP_SYSADMIN > > are going to be disappointed with what they get, but some > > level of restraint is important. > > Sure, I guess my point is, if we open up to 64, how quickly > will we hit 65. Perhaps a generic bitmask is better, and then > we need a stricter type mode anyway. Hmm, using a generic bitmask may indeed be a good idea. Though the main complication with 64-bit is communication with userspace, the rest is simple. How would we generically communicate the generic bitmap caps to userspace? The way xattrs are, pass in a buffer, and a NULL buffer to query size? Or do we still version by number of longs in the bitmaps? thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html