The Future of Linux Capabilities ...

From: Herbert Poetzl
Date: Sun Dec 26 2004 - 20:42:24 EST



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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/