Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: file effective and process inheritable mask | Date | Sat, 24 Apr 1999 00:23:14 -0400 (EDT) |
| |
Y2K writes: > On Fri, 23 Apr 1999, Albert D. Cahalan wrote:
>> The two most important extensions IMHO are: ... >> 2. The ability to mark an executable with the capabilities that were >> known to the setup tool. The kernel can use default values for any >> bits that are not listed. This lets kernel developers add new bits >> for traditionally unprivileged operations and lets them split old >> bits into more fine-grained sets of bits. > > How about CAP_LINUX_RESERVE_NORMAL_0 through CAP_LINUX_RESERVE_NORMAL_15 > being defined for future caps which are new caps that presently availible > to everyone even non-root ones.
How many is enough? I do not think we should reserve a particular number of slots. Also, that only covers the first problem.
Let's imagine that it is 2003, Linux 3.0 is out, and everybody is using capabilities. Someone decides to split CAP_DAC_READ_SEARCH into less powerful components CAP_DAC_SEARCH and CAP_DAC_READ.
Do you change the meaning of an existing bit, or do you end up with all three capabilities? If you have all three, how do they interact? If you change the meaning of an existing bit, stuff will break.
If there is a "known set" fK associated with the file, it is safe to redefine the old bit. New kernels will know that the executable does not define the new bit, so they can set it equal to the old bit.
>> After those two, I think it would be nice to allow configurations that >> are halfway between traditional behavior and the draft. One could let >> the more harmless capabilities (resources, read access...) be passed >> to child processes automatically, while enforcing the draft behavior >> for more destructive capabilities. > > Thats easily done and won't even break the draft just define the default > fI to be pP&(CAP_LINUX_RESERVE_NORMAL_0 | ... > |CAP_LINUX_RESERVE_NORMAL_15) for unmarked executable files. > you might just save yourself some trouble and say fI=pP ;->
One (or both) of us doesn't understand the other I think. What I propose could work like this:
1. The kernel calculates the draft capabilities. (call them d_pP, etc.) 2. The kernel calculates old-style values too. (call them o_pP, etc.) 3. The kernel has /proc-configurable masks. (call them p_pP, etc.) 4. This is done:
pP = (o_pP & p_pP) | d_pP;
When the mask is 0, we get draft behavior. When it is full, capabilities can be inherited in a more normal manner.
One might place these in p_pP:
CAP_DAC_READ_SEARCH CAP_KILL CAP_NET_BROADCAST CAP_IPC_LOCK CAP_SYS_BOOT CAP_SYS_NICE CAP_SYS_RESOURCE
These could be left out:
CAP_CHOWN CAP_DAC_OVERRIDE CAP_FOWNER CAP_FSETID CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_ADMIN CAP_NET_RAW CAP_IPC_OWNER CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_CHROOT CAP_SYS_PTRACE CAP_SYS_PACCT CAP_SYS_ADMIN CAP_SYS_TIME
- 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/
| |