Messages in this thread | | | Date | Mon, 19 Apr 1999 07:14:52 -0700 (PDT) | From | Y2K <> | Subject | Re: compatible capability bits |
| |
On Mon, 19 Apr 1999, Albert D. Cahalan wrote: > Capability bit defaults for an executable: > The fN value is the miNimum needed to correctly execute. > The fX value is the maXimum that this executable is trusted with. > These help protect against buggy software. > The default values for fI, fE, and fX might be adjustable. > > Files also have fK, the "bits known to the setup tool". Anything not > found in fK will be determined from the default values above. This is > important, because newly defined bits may include normal user abilities > that were simply expected when the executable was marked. It also gives > developers the ability to safely split one bit into two bits. You lost me about what fK is suppose to be. > > new_pP = fP | (fI & old_pI) | (old_pP & config_option_1 & fX); I don't like your extension because it doesn't mask with pI at the very least. Your fX is basicly my fI, and your config_option_1 is my pI which I beleive the executible should decide upon. If an program doesn't want CAP_FOO to be inherited then it shouldn't include it in pI. That way a smart binary can call other semi-trusted binaries without permanently maiming itself in the process by decreasing it's pP. > new_pE = (new_pP & fE); > new_pI = (old_pI & fX) | (new_pP & config_option_2); I do think that you are over-concerned about pI having power. The pI was designed to flow easily. pI should have been used only as a mask and never allowed to have this odd side-effect that it might interact with other files and create caps that the parent never had. This is our main point of contension. One thing that might clear things up is if I again reread the posix drafts and see if I can find any indication that this side-effect was intended or merely an over-looked aspect of the formula.
> if((new_pP & fN) != fN) return -EPERM; > I agree with this used sparingly for legacy binaries can save you some grief-- however it should be used like fE for backwards compatibility only. Maybe the user just wanted to run `foo --version` or `bar --help` ;-> > With the config options full, you get better UNIX compatibility. > With the config options empty, you get the withdrawn draft standard. > > Config options could be global, inherited, or assigned to login ID > values (which Linux does not yet support). >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |