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.
prev parent 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