Hi Andreas,
I would like to tell you that in our SnapFS project we are making extensive
use of your EA's now. The sources are available on
http://www.sourceforge.net/projects/snapfs
and a white paper with an overview is at:
http://www.mountainviewdata.com/technology/whitepapers/index.html.
SnapFS is not yet working but really pretty close. If InterMezzo needs more
metadata (which it might very well do to get further features) then we will
also use EA for that.
The atomicity constraints are very important to us, since our "ea"'s for
snapshots play a fundamental role in the file system consistency.
What Stephen is getting at is partly that such modifications of attributes
need to be possible in the context of a journal file system transaction (we
are planning to add code to your ea stuff to do that with Reiser and Ext3).
I really like your API but I also do see the point for Stephen's families.
If XYZ-fs has support for XYZ-acl's but not for extended attributes (and
systems like AFS, Coda and DFS do so) then it is advantageous to them to
merely support the family, not the general EA interface.
At the end, these are just refinements of your ideas, not fundamental
differences I think.
Thanks for getting EA out - we are _serious_ users!
- Peter -
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Andreas
> Gruenbacher
> Sent: Tuesday, October 24, 2000 5:35 PM
> To: Stephen C. Tweedie
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> Theodore Ts'o; Hans Reiser; Daniel Phillips; Andreas Dilger; Ben LaHaise
> Subject: Re: [PROPOSAL] Extended attributes for Posix security
> extensions
>
>
> On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
>
> > [...]
> > Our proposed kernel API looks something like this:
> >
> > sys_setattr (char *filename, int attrib_family, int op,
> > struct attrib *old_attribs, int *old_lenp,
> > struct attrib *new_attribs, int new_len);
> >
> > sys_fsetattr(int fd, int attrib_family, int op,
> > struct attrib *old_attribs, int *old_lenp,
> > struct attrib *new_attribs, int new_len);
> >
> > where <op> can be
> >
> > ATR_SET overwrite existing attribute
> > ATR_GET read existing attribute
> > ATR_GETALL read entire ordered attribute list (ignores new val)
> > ATR_PREPEND add new attribute to start of ordered list
> > ATR_APPEND add new attribute to end of ordered list
> > ATR_REPLACE replace entire ordered attribute list
> >
> > and where <attribs> is a buffer of length <len> bytes of variable
> > length struct attrib records:
> >
> > struct attrib {
> > int rec_len; /* Length of the whole record:
> > should be padded to long
> > alignment */
> > int name_family; /* Which namespace is the
> name in? */
> > int name_len;
> > int val_len;
> > char name[variable]; /* byte-aligned */
> > char val[variable]; /* byte-aligned */
> > };
> > [...]
>
> The main point I see here is the ability to manipulate a number of
> attributes as an atomic operation. I really don't understand what you mean
> by an ordered attribute list.
>
> There are a number of features that could be implemented at the syscall
> interface. The things I have in mind range from get-and-set, manipulating
> multiple attributes atomically, to some sort of mini-language specifying
> more complicated transactions. Some sort of database transactions is right
> out of the question.
>
> All these things complicate the EA syscall interface and implementation
> considerably. One main goal for the syscall interface for me was
> simplicity. I still fail to see a real need for any of the features
> mentioned above.
>
> Stephen, maybe you can enlighten me why you think your interface is the
> minimal interface required?
>
> > Additionally, the use of well-defined namespaces for attributes means
> > that in the future we can implement things like common code for
> > generic attribute caching, or process authentication groups for
> > non-Unix-ID authentication tokens, without having to duplicate all of
> > that work in each individual filesystem.
>
> I think different concepts (like Posix ACLs and NTFS ACLs) should be
> reflected as different EAs, not different namespaces. So instead of having
> different namespaces for Posix ACLs, Capabilities, Mandatory Access
> Control labels etc. you just have different attributes (say, "system.acl",
> "system.cap", "system.mac". For NTFS ACLs, you have yet another attribute
> name (say, "system.ntfs_acl").
>
> The point about having different types of EAs (in a unified name space)
> was to specify different permissions. You can also think of your
> namespaces as a prefix to EA names (user.mime_type, system.acl etc.)
>
> A somewhat more elaborate list of EA types might include (this originally
> was an idea of Casey Schaufler):
>
> system
> Permissions for manipulating system EAs and valid values are
> determined by the kernel on a per-attribute bases.
>
> user
> Permissions for manipulating user EAs are subject to the same
> restrictions as manipulating the file's contents.
>
> trusted
> There attributes may only be manipulated by trusted subsystems (maybe
> determined by a special capability).
>
> inode
> Permissions for manipulating inode EAs are subject to the same
> restrictions as manipulating an inode's attributes.
>
> (I'm not sure inode EAs serve any need.)
>
> > The extended attribute patch currently on the acl-devel group simply
> > doesn't give us the ability to do extended attributes on any
> > filesystem other than ext2, because it has such specific semantics.
> > I'd rather avoid that, and I'd rather do so without adding a profusion
> > of different ACL and attribute syscalls in the process.
>
> I really don't see why you think the semantics are "specific". They are
> simple--on purpose, and for good reason. What makes them specific in your
> opinion?
>
>
> Andreas
>
> ------------------------------------------------------------------------
> Andreas Gruenbacher, [EMAIL PROTECTED]
> Contact information: http://www.bestbits.at/~ag/
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
