The Future of Linux Capabilities ...

[Herbert Poetzl]

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/