Messages in this thread | | | Date | Tue, 21 Oct 2003 06:26:45 -0500 (CDT) | From | "Michael Glasgow" <> | Subject | posix capabilities inheritance |
| |
I wrote a simple setuid-root wrapper which sets some capabilities, gives up all other privs, and and then execs a shell. I was hoping to use this wrapper as a login shell so that I could have a user log in interactively with a small subset of elevated privileges.
Unfortunately after looking over the capabilities code in the 2.4 kernel, it would appear that this is not currently possible, and my wrapper cannot work without filesystem support for capabilities. And even then, I'd have to set each file's inheritable flag for the capabilities I want on every executable that I am likely to run, including the shell. Am I mising something, or is this an accurate description?
I think I understand the rationale behind this behavior; the draft posix 1003.1e specification states:
The purpose of assigning capability states to files is to provide the exec() function with information regarding the capabilities that any process image created with the program in the file is capable of dealing with and have been granted by some authority to use.
So, the lack of an inheritable flag on a file can serve to prevent that file from executing with the corresponding capability enabled.
Fine, but what about my semi-superuser shell situation? How can I force the retention of a capability set across exec() for all executables? It would seem that neither the spec nor the current implementation in the 2.4 kernel allow for this, but it strikes me as a pretty reasonable and useful thing to do in some cases.
As an interim workaround, how about assuming all capabilities are inheritable in fs/exec.c:prepare_binprm, i.e. instead of cap_clear(bprm->cap_inheritable), call cap_set_full() ??? I don't think this would break anything, and it would make capabilities a lot more useful until we get fs support merged in.
-- Michael Glasgow < glasgow at beer dot net > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |