Messages in this thread | | | Subject | Re: [RFC] [PATCH] file posix capabilities | From | Nicholas Miell <> | Date | Tue, 15 Aug 2006 12:31:02 -0700 |
| |
On Tue, 2006-08-15 at 07:20 -0500, Serge E. Hallyn wrote: > Quoting Serge E. Hallyn (serge@hallyn.com): > > > Make it an arbitrary length bitfield with a defined byte order (little > > > endian, probably). Bits at offsets greater than the length of the > > > bitfield are defined to be zero. If the kernel encounters a set bit that > > > it doesn't recognizes, fail with EPERM. If userspace attempts to set a > > > bit that the kernel doesn't recognize, fail with EINVAL. > > > > > > It's extensible (as new capability bits are added, the length of the > > > bitfield grows), backward compatible (as long as there are no unknown > > > bits set, it'll still work) and secure (if an unknown bit is set, the > > > kernel fails immediately, so there's no chance of a "secure" app running > > > with less privileges than it expects and opening up a security hole). > > > > Sounds good. > > > > The version number will imply the bitfield length, or do we feel warm > > fuzzies if the length is redundantly encoded in the structure? > > nm, 'encoded in the structure' clearly is silly. >
There isn't really a version number, just recognized and unrecognized capability bits. If you wanted, you could use a single byte to give a binary CAP_DAC_OVERRIDE, with capability bits 8-30 being "stored" in not-present bytes and therefore assumed to be zero.
-- Nicholas Miell <nmiell@comcast.net>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |