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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.