Re: cap set name change

Y2K (y2k@y2ker.com)
Wed, 21 Apr 1999 18:00:29 -0700 (PDT)

On Wed, 21 Apr 1999, Albert D. Cahalan wrote:
> Considering your plans to change behavior...
> Please do not use the draft names without the draft behavior.
> It will cause confusion, and security-related confusion is dangerous.
Its a dead withdrawn draft, I'll make sure I put derived from withdrawn
posix draft disclaimer in a .sig or something.
> Avoid these names:
> fI, fE, fP, pI, pE, pP, inheritable, inherited, effective, permitted
Kind of hard since I'm interfacing with pre-existing linux facilities.
current->cap_permitted capabilities.h CAP_SETUID all looks kind of like
those terms.
> It would be best to avoid the whole "capabilities" term, which already
> causes confusion with a "pure capabilities" system. Try "privileges".
Maybe I'll call it soiled capabilities;->
> Since you clearly do intend to break compatibility with the draft,
> you might as well simplify down to a single set of bits as well.
> (well, a "known bits" and "minimum needed" would reduce accidents)
Actually I'm bending and detailing it quite roughly, but off top of head
can't see where I've broken it;->
Default setings for fP fI fE where never mentioned AFAICS.
I am also actually using stricter formulas than in the draft.
I beleive there was a section that said extensions were OK as long as they
more restrictive. I also think it is interesting when people say my
porposal is less secure when it is more restrictive.
My patch should at least be something to think about and has useful
behavior for some people to play with RSN.
Besides it seems like I might be the lone lunatic here, I'm sure a few
people who disagree with me could start coding and produce something more
to their liking.

--
Warning when I mention capabilites I mean "soiled" capabilities not "pure".
Any caps I mention are *derived* from a withdrawn draft posix document.




-
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/