Messages in this thread | | | Date | Sat, 24 Apr 1999 09:36:35 -0700 (PDT) | From | Y2K <> | Subject | Re: file effective and process inheritable mask |
| |
On Sat, 24 Apr 1999, Albert D. Cahalan wrote: > Ugh. Some people have very old executables. It is never really safe > to make random old privileged executables crash. Well I quess that you should have to use cap_from_text() which is in the standard add a few fake caps that really are groups of other real caps. Then if you kill CAP_DAC_READ_SEARCH later on you can expand it behind the scenes later by just making it a fake cap that really is a set of real caps. > > Define a few fatter profiles like power, normal, net_power,net_normal, > > file_power, file_normal, reserved_power, reserved_normal, power_admin > That won't solve the problem, but it is a nice idea anyway. Yes I guess you have to resolve some things at run time. > > Yes I what to strengthen the formula not weaken it. > > pP'= (fP & x) | (fI & pI & pP) > > for proper files x can be ~0 otherwise 0 . > Your pP' fits into my equation as d_pP. (but it is broken) you think it is broken cause I think pI and fI should be strictly a limiting factor they should never cause a child process to gain caps the parent never had. > Notice that my equation is _not_ the pP equation from the draft. > The draft produces d_pP, and o_pP is something lenient. > They are combined using a configurable mask. I don't want lenient, I want more strictness on how caps are gained ie. through fP *only* .
-- 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/
| |