From: Pavel Machek <pavel@ucw.cz>
To: Theodore Tso <tytso@mit.edu>, David Madore <david.madore@ens.fr>,
Linux Kernel mailing-list <linux-kernel@vger.kernel.org>
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)
Date: Mon, 11 Sep 2006 10:09:02 +0200 [thread overview]
Message-ID: <20060911080901.GC1898@elf.ucw.cz> (raw)
In-Reply-To: <20060910232412.GE22892@thunk.org>
Hi!
> > > absence of an explicit capability record. Both of these should be
> > > overrideable by a mount option, but for convenience's sake it would be
> > > convenient to be able to set these values in the superblock.
> >
> > Would per-system default capability masks be enough? ... .... okay,
> > probably not, because nosuid is per-mount, and this is similar.
>
> Per system defaults would also be good, but I believe it would also be
> a good idea for their to be per-filesystem defaults. Yes, not all
> filesystems would support per-filesystem defaults, since this requires
> extensions in their superblock; for those, they would only have the
> per-system defaults.
Aha, okay... David, doing global defaults should be very easy, as
should be doing ext3 example conversion...
> > > As far as negative capabilities, I feel rather strongly these should
> > > not be separated into separate capability masks. They can use the
> > > same framework, sure, but I think the system will be much safer if
> > > they use a different set of masks. Otherwise, there can be a whole
> > > class of mistakes caused by people and applications getting confused
> >
> > Can we simply split them at kernel interface layer? Libc could do it,
> > preventing confusion...
>
> But that means libc would need to know which bit positions were
> positive capabilities, and which were negative, and adding new
> capabilities would require a matching change with libc. Not a good
> idea, I think....
Okay, I guess we could hardcode the mask (top 16 capabilities are
"normal") but yes, I see your point now. We probably want different
syscalls, even if underlying implementation shares the code...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-09-11 8:09 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 21:26 patch to make Linux capabilities into something useful (v 0.3.1) David Madore
2006-09-06 0:27 ` Casey Schaufler
2006-09-06 10:06 ` David Madore
2006-09-06 13:26 ` David Madore
2006-09-07 0:11 ` Casey Schaufler
2006-09-07 0:32 ` David Madore
2006-09-07 1:01 ` Casey Schaufler
2006-09-07 1:29 ` David Wagner
2006-09-07 16:00 ` Casey Schaufler
2006-09-07 18:33 ` David Wagner
2006-09-07 17:34 ` David Madore
2006-09-07 19:38 ` Bernd Eckenfels
2006-09-07 23:00 ` Pavel Machek
2006-09-08 1:22 ` Bernd Eckenfels
2006-09-08 10:45 ` Pavel Machek
2006-09-08 16:08 ` Casey Schaufler
2006-09-08 14:39 ` Pavel Machek
2006-09-08 19:10 ` Bernd Eckenfels
2006-09-07 22:54 ` Pavel Machek
2006-09-08 4:10 ` David Madore
2006-09-08 10:52 ` Pavel Machek
2006-09-08 22:51 ` David Madore
2006-09-09 0:11 ` Casey Schaufler
2006-09-09 11:59 ` Pavel Machek
2006-09-09 11:40 ` Pavel Machek
2006-09-10 10:41 ` David Madore
2006-09-10 13:06 ` Pavel Machek
2006-09-10 14:25 ` capability inheritance (was: Re: patch to make Linux capabilities into something useful (v 0.3.1)) David Madore
2006-09-10 22:42 ` Pavel Machek
2006-09-11 16:00 ` Casey Schaufler
2006-09-11 17:39 ` David Madore
2006-09-09 0:59 ` patch to make Linux capabilities into something useful (v 0.3.1) David Wagner
2006-09-09 12:49 ` David Madore
2006-09-09 23:18 ` Theodore Tso
2006-09-10 10:13 ` David Madore
2006-09-10 12:36 ` Pavel Machek
2006-09-10 23:24 ` Theodore Tso
2006-09-11 8:09 ` Pavel Machek [this message]
2006-09-06 18:25 ` Serge E. Hallyn
2006-09-06 22:27 ` David Madore
2006-09-07 0:04 ` David Madore
2006-09-07 23:06 ` Serge E. Hallyn
2006-09-08 4:16 ` David Madore
2006-09-07 6:43 ` Jan Engelhardt
2006-09-07 23:02 ` Serge E. Hallyn
2006-09-08 1:08 ` David Madore
2006-09-08 1:31 ` Serge E. Hallyn
2006-09-08 21:45 ` David Madore
2006-09-07 18:21 ` James Antill
2006-09-07 18:33 ` Kyle Moffett
2006-09-07 20:05 ` James Antill
2006-09-08 4:00 ` David Madore
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=20060911080901.GC1898@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=david.madore@ens.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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