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]
