From: "Theodore Ts'o" <tytso@mit.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: Posix capabilities
Date: Thu, 17 Oct 2002 08:20:56 -0400 [thread overview]
Message-ID: <20021017122056.GB13573@think.thunk.org> (raw)
In-Reply-To: <20021017120526.GC6014@TK150122.tuwien.teleweb.at>
On Thu, Oct 17, 2002 at 02:05:26PM +0200, Stefan Schwandter wrote:
> Ah, ok... I thought that things work like this: the capabilities support
> already is in the kernel, and to give an app a particular capability,
> one has to add a particalar extended attribute to the application
> executable. So I'm wrong here it seems?
First of all, you can't use a standard user extended attribute, since
anyone with write access to the file will be allowed to set the
extended attribute. This isn't good if you're going to be granting
root-privileged capabilities to executables!
So what would be needed is code to set and get a special system xattr
(much like the POSIX ACL patches do) that is specifically set up for
capabilities, and with appropriate authorization access checks when
setting the capability xattr. In order to do that, we would have to
decide on the actual on-disk format encoding for capabilities (and one
which hopefully is extensible so that when additional capabilities are
added in the future, existing filesystems with capability attributes
remain backwards compatible). Finally, the ELF loader would have be
modified to read the capability extended attribute from the
executable, decode the xattr, and then set the capability masks
appropriately.
The code which I posted is a prerequisite for the above work, yes.
It's just that there's quite a bit of additional work that would be
necessary. (And this is all aside from the question about whether or
not it's a good idea for most system administrators to attempt to use
such a system once it was fully implemented.)
- Ted
next prev parent reply other threads:[~2002-10-17 12:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-16 15:44 Stefan Schwandter
2002-10-16 16:22 ` Bosko Radivojevic
2002-10-17 3:26 ` Theodore Ts'o
2002-10-17 4:00 ` GrandMasterLee
2002-10-17 13:22 ` Horst von Brand
2002-10-18 6:38 ` GrandMasterLee
2002-10-17 10:37 ` Olaf Dietsche
2002-10-17 11:02 ` Andreas Gruenbacher
2002-10-17 12:12 ` Theodore Ts'o
2002-10-17 15:36 ` Olaf Dietsche
2002-10-17 17:17 ` Alex Riesen
2002-10-18 16:13 ` Rogier Wolff
2002-10-17 13:40 ` Henning P. Schmiedehausen
2002-10-17 12:05 ` Stefan Schwandter
2002-10-17 12:20 ` Theodore Ts'o [this message]
2002-10-20 14:16 ` Pavel Machek
2002-10-27 13:46 ` Andreas Gruenbacher
2002-10-17 20:43 Neil Schemenauer
2002-10-20 14:18 ` Pavel Machek
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=20021017122056.GB13573@think.thunk.org \
--to=tytso@mit.edu \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®