Hi!
> 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
> 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 ...
1) seems acceptable, as long as 64bits is enough. 2) looks ugly.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Pavel Machek <[email protected]> writes:
> 1) seems acceptable, as long as 64bits is enough.
That cries for an extensible interface.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sun, Jan 02, 2005 at 08:43:31PM +0100, Andreas Schwab wrote:
> Pavel Machek <[email protected]> writes:
>
> > 1) seems acceptable, as long as 64bits is enough.
>
> That cries for an extensible interface.
I guess using an array (with at compile time fixed size)
of __u32 (or maybe __u64 on 64bit archs) would be a good
solution to make it 'compatible' with the current interface
(for the lower 32 bit) and allow to use an interface which
can handle arbitrary sizes for the 'new' syscall interface
best,
Herbert
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, [email protected]
> SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> _______________________________________________
> Vserver mailing list
> [email protected]
> http://list.linux-vserver.org/mailman/listinfo/vserver