Quoting Andrew Morgan ([EMAIL PROTECTED]): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> 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'm confused. Could you say that again? If we up the kernel capabilities > to 64-bit and define support for 64-bit file capabilities how does this > not simplify the implementation of file capabilities with an eye to the > future?
Quite simple - if we don't accomodate a 64-bit file capability format in 2.6.24, then you won't be able to run certain binaries from a slightly newer distro on plain 2.6.24. Whereas having 64-bit *process* capabilities in 2.6.24 or not makes no difference if you want to run a slightly newer distro on 2.6.24. I realize you don't want to do that anyway (and actually I don't want to either), but some do. > > 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? > > I need to think some more about this. Ok. 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
