Re: The Future of Linux Capabilities ...

[Ulrich Drepper]

On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl <herbert@xxxxxxxxxxxx> wrote:
>   II)   add 32 (or more) sub-capabilities which depend
>         on the parent capability to be usable, and add
>         appropriate syscalls for them.
> 
>         example: CAP_IPC_LOCK gets two subcapabilities
>         (e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which

I won't try to say anything about III, but I is not really suitable,
it breaks code currently using capabilities.  Or at least makes them
less secure.  With sub-capabilities the interface diverges from the
POSIX capabilities interfaces, but at least one can keep backward
compatibilities.

An alternative would be to keep the existing capabilities, and add new
ones for all the cases which need splitting.  If the old value is
set/reset, all the split-out values are "magically" affected as well. 
This would help keeping the interfaces in line with POSIX and no
additions to the userlevel libcap would be needed.  Yes, new cap[gs]et
syscalls would be needed, but this fact is hidden from the user.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/