public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Herbert Poetzl <herbert@13thfloor.at>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-VServer <vserver@list.linux-vserver.org>
Subject: The Future of Linux Capabilities ...
Date: Mon, 27 Dec 2004 02:40:41 +0100	[thread overview]
Message-ID: <20041227014041.GA30550@mail.13thfloor.at> (raw)


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






             reply	other threads:[~2004-12-27  1:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-27  1:40 Herbert Poetzl [this message]
2004-12-27 19:36 ` The Future of Linux Capabilities Pavel Machek
2005-01-02 19:43   ` Andreas Schwab
2005-01-03  0:04     ` [Vserver] " Herbert Poetzl
2004-12-27 23:22 ` Ulrich Drepper
2004-12-28  2:21   ` Herbert Poetzl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041227014041.GA30550@mail.13thfloor.at \
    --to=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=vserver@list.linux-vserver.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox