public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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