> (I've cc'ed Ted T'so, because he's credited as a contributor in the
OK, me too. (is this desired or annoying?)
> pP' = fP | ( fI & pI ).
>
> Or in other words, the process' permitted set becomes the combination of
> the permitted set of the exec()'d file and those inheritable capabilities
> of the exec()ing file that are also inheritable by the file."
>
> This means that, not only is the permitted set important for a
> file (which works fine under setuid0), but also important is the
> inheritable set; i.e., setting the inheritable set should be a priviledged
> operation, and in the absence of permitted or inheritable sets, a new file
> should execute with no capabilities.
There is a difference between "no capabilities" and "undefined capabilities".
The kernel can do whatever is best for the undefined case, perhaps under
the influence of a configuration option.
> Let's consider the chown(1) program, for a nice, concrete example.
>
> - CAP_CHOWN is the capability required for changing the owner of a file.
>
> - The CAP_CHOWN cap should be flagged in the inheritable set of the chown
> binary, and if it's also flagged in the inheritable set of the parent
> process, chown(1) should be capable of setting the file owner.
This is getting really silly of course. It means you have to give
special rights to emacs, dd, perl, patch, gzip, tar, ln, gcc...
If you really are that insane, you can have a config option for it.
I doubt that it is helpful to require that every tool have bits set.
> I think the problem I've pointed out is a show-stopper for the
> setuid0 solution.
Eh, what problem?
-
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/