Messages in this thread | | | Date | Mon, 27 Dec 2004 02:40:41 +0100 | From | Herbert Poetzl <> | Subject | The Future of Linux Capabilities ... |
| |
Hi Linus! Hi Folks!
as linux-vserver is heavily using (and depending) on the linux capability system, and we are always trying to improve things for users and developers I wonder how the future of this capability system looks like ...
I would not spend too much time on that, if we would not need to improve that system by splitting up (or working around) some capabilities which are too coarse (or too general) to be useful ...
good examples for such capabilities are:
#define CAP_NET_ADMIN 12
/* Allow locking of shared memory segments */ /* Allow mlock and mlockall (which doesn't really have anything to do with IPC) */
#define CAP_IPC_LOCK 14
#define CAP_SYS_ADMIN 21 #define CAP_SYS_RESOURCE 24
especially CAP_NET_ADMIN and CAP_SYS_ADMIN contain more than 20 different aspects ...
we are currently aware of three different solutions to refine the capability system, and I would like to hear some opinions and get a statement from mainline (good, impossible, crap, don't care, or whatever ;)
I) extend the capability type kernel_cap_t to 64 (or more) bit, add new syscalls cap*64() and let the 'old' interface just see the lower 32 bit
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
III) (linux-vserver specific solution) add a (compile time) CAP_MASK to declare which caps have subcaps, then use per context subcaps for known subfeatures and an additional cap_t to cover 'all other' aspects of the capability
example: CAP_IPC_LOCK in CAP_MASK, plus the SCAP_MEM_LOCK subcapability, now having IPC_LOCK in the tasks caps doesn't do anything without the corresponding IPC_LOCK in the context or the SCAP_MEM_LOCK capability where appropriate
I think that all three solutions are usable for our project, so I can live pretty well with III, but I think refining the capability system might be something which is useful for mainline ...
TIA, Herbert
- 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/
| |