Extended attribute interfaces

[Andreas Gruenbacher]

On Sun, 17 Sep 2000, Robert Watson wrote:

> Andreas,
> 
> Sorry about the delay in getting back to you -- the last week or two has
> been non-stop paper preparation for the upcoming BSDcon.  I'll be
> presenting a paper there on TrustedBSD EA+Capability implementation, among
> other things :-). 

Are there any previews of your paper(s) available for taking a look?

> On Fri, 8 Sep 2000, Andreas Gruenbacher wrote:
> 
> <snip>
> > I don't think it makes sense to treat root differently from anybody
> > else, particularly not on a CAP-enabled system.
> 
> What I had in mind was whether privilege allowed violation of the normal
> restricted system EAs.

Like setting an invalid ACL? For Posix.1e the rules are well defined who
is allowed to change which information when; these rules should not be
allowed to be bypassed at all.

> In the context of specific system EA handlers,
> this isn't a useful question, as it can be per-EA as makes sense.  In my
> current model, I don't have system EAs with specific handlers, instead the
> special semantics for the EA are either maintained at the FS level, or in
> the code that makes use of the EA.

There shouldn't be any policies at the FS layer. Think of supporting
multiple file systems, that pretty soon gets a mess. It should really be
in `the code that makes use of the EA'. That code needs to be in the
kernel, or otherwise the policy would not be enforced. Whether you're
using some sort of handler or whatever other mechanism doesn't matter of
course.

> > The attribute namespaces '$*' and '[A-Za-z]*' have deliberately been
> > chosen so that it's possible to add other prefixes later should that
> > become necessary.
> > 
> > One thing I have been discussing recently was how to name EAs for which
> > it makes no sense to back them up (for all '$*' and '[A-Za-z*]'
> > attributes defined so far it makes sense to include them in
> > backup/restore). We might want to reserve another prefix (say, '.', '&',
> > ...) for non-backup system attributes. Just a thought...
> 
> One nice aspect to the POSIX.1e capabilitiy, ACL, et al interfaces, is
> that they are appropriate for use when backing up files.  To get a
> portable backup you perform acl_get_file() followed by acl_to_text().  The
> binary storage in EAs is probably necessarily OS-dependent, and possibly
> dependent on the hardware platform.

What is generated by acl_to_text isn't ideal for backup purposes,
either. You are loosing the mapping between user IDs and user names (in
tar files, both user/group names and their IDs are stored, for
example). Nevertheless it's far superior to any binary, OS specific,
format.

> As such, my point of view thus far
> has been that system EAs should generally only be backed up using the
> mechanism provided by their handler.  This could mean doing the conversion
> (possibly only a typecast) in userland via the ACL library, or via some
> mangling in kernel via a syscall.  But it would mean that userland code
> would not, in the general case, be required to attempt to backup system
> EAs.

The external representations can only be computed in userspace (think of
looking up a user name for a given user ID, which may even involve
something like NIS, for example). I prefer to keep the
kernel-to-user-space interface simple (perhaps even as simple as it is
now).

Backup utilities should really not back up things like ACLs, capabilities
and the like in their binary representation, that's for sure---ideally
they should convert them into a portable representation. However there
currently are no agreed formats for that, and there may also be attributes
backup utilities are not aware of. I assume it's better to back these up
in binary form rather than not back them up at all.

A system call interface similar to the one I have implemented right now,
and which we have also been talking about, allows this.


Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/








To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message