> Here is a patch to support uid/gid/fsuid/fsgid passing over unix
> domain sockets. I think this is a better solution than a
> set_hid_call because it is easily extensible to capabilities. This
> patch is not 100% finished, but uid/gid passing does work.
>
Cool! I like this! :-)
Just two comments which are really based on the same problem:
- Being able to pass to the _effective_ set of the receiving process
makes it possible to pass on a non-mutable capability since you are
not allowed to move a capability from the effective set to the
permitted set. This can be useful in certain situations.
- Should you be able to pass on uid/gid without having any sort of
extra privileges?
Both of these "issues" come from the fact that we don't have a
`mutable' bit associated with our credentials. There is no difference
between a process "owning" your uid and a process that just lends your
uid while performing a task. A program that just lends an uid and
pass it on _could_ lead to trouble [however, defending against that
kind of abuse (trojan horse) is really difficult in UNIX
anyway]. Passing capabilities to the effective set of another process
emulates giving them a capability with the mutable bit cleared. I
don't know of a way to emulate a mutable-less uid/gid in the same way.
So, to be on the safe side, we could have a CAP_MUTABLE which
indicates that the uid/gid/fsuid/fsgid and capabilities of the process
are mutable - i.e. the process is allowed to give them away. It is
coarse-grained, but probably better than nothing. When this patch is
integrated in the kernel, I really see no reason to keep CAP_SETPCAP
at all, so the number of capabilities wouldn't change.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
- 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.altern.org/andrebalsa/doc/lkml-faq.html