The semantics of "nosuid" file systems is that they don't allow exec
if the "id" has changed. With capabilities, if the new process has
some permitted capability that the original doesn't have, we call it
an "id" change. The effective capabilities are always a subset of the
permitted, unless somebody has exercised their powers through the
CAP_SETPCAP capability to do some "illegal" operation, so we use the
permitted when referring to the "capabilities" of the process.
When we exec a suid program and are in compatible mode, we generally
raise the effective and permitted capabilities. This will set the "id"
changed variable and the exec isn't allowed.
This means that the mounting a file system nosuid will still work as
expected.
However, it would certainly be interesting to have no-forced,
no-allowed, and maybe even no-smart when we get a capability-aware
ext2 file system.
>
> If we can agree to the following constraint, I will withdraw my
> objection to CAP_SETPCAP:
>
> (as Alan suggests here) we build in a "no-[capability list]" mount
> option for mounting filesystems. That is to say, a sys-admin can
> trust a filesystem to reliably manipulate only a subset of the
> total capabilities known to the system.
>
Currently we read all capabilities as { 0 } from the file system. This
means that a list of capabilities to mask the "forced", "allowed" or
"smart" bits through have no effect. It is probably a good idea to
have something like this when we have capability support in the file
system and there is something to filter.
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