All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: Russell Coker <russell@coker.com.au>, reiserfs-list@namesys.com
Subject: Re: xattr
Date: 19 Jun 2003 14:06:35 -0400	[thread overview]
Message-ID: <1056045995.6758.139.camel@tiny.suse.com> (raw)
In-Reply-To: <1056043514.1071.199.camel@moss-huskers.epoch.ncsc.mil>

On Thu, 2003-06-19 at 13:25, Stephen Smalley wrote:
> On Thu, 2003-06-19 at 11:21, Chris Mason wrote:
> > Ok, so in the new api, the xattr information is available at the time of
> > the create.  reiserfs would be able to include it all into the same
> > transaction but doesn't do it right now.
> 
> This was true of the old API as well; the only difference is whether the
> attribute is specified as a parameter to an extended open/mkdir/etc call
> or whether it is set separately as a process attribute that is applied
> to subsequent ordinary open/mkdir/etc calls.  Including the setxattr in
> the same transaction as the create is not strictly necessary, although
> it would be nice.  The SELinux API change didn't change the create+set
> atomicity, which is still provided by performing the set before the
> parent directory semaphore is released.
> 

Ok, I get it.  You would need a special reiserfs xattr add on patch to
get the atomicity right.

> > First we need to get the data logging code in (which Hans has agreed
> > to), getting the xattr code in depends on Hans, Jeff Mahoney will be
> > maintaining as an external patch otherwise.
> 
> My impression (possibly wrong) is that Hans prefers a EA-as-file model,
> which I understand is also the Solaris model.  The key question then
> becomes whether mainline reiser{3,4} will ever support the xattr inode
> operations (e.g. implementing them as reads/writes of the EA files
> associated with the inode).  If not, then neither the SELinux "module"
> nor the SELinux userland will be able to access file security attributes
> on reiser{3,4} in the same manner as on ext[23], xfs, or jfs.

The reiserfsv3 xattr patches maintained by SuSE implement the xattr api
(acl.bestbits.at).  The xattrs happen to be implemented as individual
files on disk because reiserfs is so well suited for it, and because it
allowed Jeff to code them without changing the v3 disk format.

But, these files are only available through the xattr api right now, and
they are not visible via tools like ls etc.

Not sure how namesys is doing things in version 4, but I'd bet they are 
willing to talk about making it work with SELinux.

-chris



  reply	other threads:[~2003-06-19 18:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-16 12:26 xattr Russell Coker
2003-06-17 11:04 ` xattr Hans Reiser
2003-06-19 13:52 ` xattr Chris Mason
2003-06-19 14:46   ` xattr Russell Coker
2003-06-19 14:55     ` xattr Chris Mason
2003-06-19 15:12       ` xattr Russell Coker
2003-06-19 15:10     ` xattr Stephen Smalley
2003-06-19 15:21       ` xattr Chris Mason
2003-06-19 17:25         ` xattr Stephen Smalley
2003-06-19 18:06           ` Chris Mason [this message]
2003-06-19 18:52             ` xattr Stephen Smalley
2003-06-19 18:55             ` how to fix the file system which has a dangling file? bmoon
2003-06-23  7:56   ` xattr Hans Reiser
     [not found] <200312021433.48383.russell@coker.com.au>
2003-12-02 14:45 ` xattr James Carter
2003-12-02 14:45 ` xattr James Carter

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=1056045995.6758.139.camel@tiny.suse.com \
    --to=mason@suse.com \
    --cc=reiserfs-list@namesys.com \
    --cc=russell@coker.com.au \
    --cc=sds@epoch.ncsc.mil \
    /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.