Messages in this thread | | | Date | Mon, 27 Dec 2004 15:22:32 -0800 | From | Ulrich Drepper <> | Subject | Re: The Future of Linux Capabilities ... |
| |
On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl <herbert@13thfloor.at> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |