Quoting Andrew Morgan ([EMAIL PROTECTED]): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> The code you are contemplating now which reserves a magic number for > >> 64-bits and we can't use that magic number; we've created a legacy we > >> can't use. > > > > I think that's very unlikely. I expect us to get to 33, maybe 34 or 35, > > capabilities "real soon now", but take a long time to go beyond that. > > Then, after all, perhaps it is time to just introduce file capabilities > with a simultaneous kernel change to 64-bits now, while all this support > is experimental?
Well we could try, but whereas the 64-bit file capabilities may be justified by people wanting the current kernel to work with future capabilities, introducing 64-bit caps doesn't help that way. I did think you might end up introducing a new bit to control switching between root-user and capabilities for a process, or for adding to the bset. So we could introduce the per-process cap_bset now, along with a new capability bit? -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
