From: Ulrich Drepper <drepper@gmail.com>
To: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-VServer <vserver@list.linux-vserver.org>
Subject: Re: The Future of Linux Capabilities ...
Date: Mon, 27 Dec 2004 15:22:32 -0800 [thread overview]
Message-ID: <a36005b5041227152268e68af9@mail.gmail.com> (raw)
In-Reply-To: <20041227014041.GA30550@mail.13thfloor.at>
On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl <herbert@13thfloor.at> wrote:
> 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
I won't try to say anything about III, but I is not really suitable,
it breaks code currently using capabilities. Or at least makes them
less secure. With sub-capabilities the interface diverges from the
POSIX capabilities interfaces, but at least one can keep backward
compatibilities.
An alternative would be to keep the existing capabilities, and add new
ones for all the cases which need splitting. If the old value is
set/reset, all the split-out values are "magically" affected as well.
This would help keeping the interfaces in line with POSIX and no
additions to the userlevel libcap would be needed. Yes, new cap[gs]et
syscalls would be needed, but this fact is hidden from the user.
next prev parent reply other threads:[~2004-12-27 23:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-27 1:40 The Future of Linux Capabilities Herbert Poetzl
2004-12-27 19:36 ` Pavel Machek
2005-01-02 19:43 ` Andreas Schwab
2005-01-03 0:04 ` [Vserver] " Herbert Poetzl
2004-12-27 23:22 ` Ulrich Drepper [this message]
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=a36005b5041227152268e68af9@mail.gmail.com \
--to=drepper@gmail.com \
--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