Re: compatible capability bits
Y2K (y2k@y2ker.com)
Mon, 19 Apr 1999 07:14:52 -0700 (PDT)
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/