public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de>
Cc: viro@math.psu.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] 2.5.42 (1/2): Filesystem capabilities kernel patch
Date: Tue, 22 Oct 2002 00:03:32 +0200	[thread overview]
Message-ID: <200210220003.32601.agruen@suse.de> (raw)
In-Reply-To: <87fzuzke5m.fsf@goat.bogus.local>

Hi,

I believe that Capabilities on the file system are a useful thing. They 
obviously also are quite controversial. If deployed without the right tools 
they may certainly lead to less secure systems. So these supporting tools 
need to be develped first, and some real-world experience seems necessary to 
learn more.

Whatever the result of this process will be, should we decide to have 
filesystem capabilities we would need to associate some pieces of information 
with individual inodes, and this is exactly what Extended Attributes were 
designed for. There are implementations for ext2, ext3, jfs, xfs, reiserfs, 
so I think it makes no sense to reinvent the wheel. (Xattrs (or EAs) were 
actually not invented for Linux; Irix and other OSes support almost identical 
schemes.)

Do you happen to know the attr(5) manual page? An online version is available 
at <http://acl.bestbits.at/cgi-man/attr.5>; perhaps that helps.

--Andreas.

On Monday 21 October 2002 17:25, Olaf Dietsche wrote:
> Andreas Gruenbacher <agruen@suse.de> writes:
> > Capabilities should be implemented as extended attributes;
>
> Why "should" this be implemented as extended attributes? What are the
> benefits in doing so?
>
> > see Ted's recent postings.
>
> Ted's recent postings argue against capabilities at all. So what do
> you mean?
>
> Regards, Olaf.


      reply	other threads:[~2002-10-21 21:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 19:07 [PATCH][RFC] 2.5.42 (1/2): Filesystem capabilities kernel patch Olaf Dietsche
2002-10-18 23:00 ` Alexander Viro
2002-10-19  0:07   ` Olaf Dietsche
2002-10-19  0:25     ` Alexander Viro
2002-10-24 12:25       ` [PATCH][RFC] 2.5.44 " Olaf Dietsche
2002-10-28 22:56         ` Olaf Dietsche
2002-10-28 23:36           ` chris
2002-10-29  0:20             ` Olaf Dietsche
2002-10-29  1:08               ` Olaf Dietsche
2002-10-29 11:08                 ` Olaf Dietsche
2002-10-29 11:18                 ` Chris Evans
2002-10-29  2:23             ` Andreas Gruenbacher
2002-10-29 11:09               ` Olaf Dietsche
2002-10-29 11:35                 ` Andreas Gruenbacher
2002-10-29 12:04                 ` __libc_enable_secure check (was: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch) Olaf Dietsche
2002-10-29 14:38                 ` [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch Olaf Dietsche
2002-10-20  0:24 ` [PATCH][RFC] 2.5.42 " Andreas Gruenbacher
2002-10-21 15:25   ` Olaf Dietsche
2002-10-21 22:03     ` Andreas Gruenbacher [this message]

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=200210220003.32601.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf.dietsche#list.linux-kernel@t-online.de \
    --cc=viro@math.psu.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