On Tue, 31 Oct 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Sun, Oct 29, 2000 at 03:15:57PM +0100, Andreas Gruenbacher wrote:
> >
> > The interface described here also doesn't include Stephen's idea to allow
> > an ordered list of EA's under the same name. In addition to the append and
> > prepend operations Stephen suggested, a whole range of other operations
> > (get/delete/... by index, etc.) might make sense, and stuff like that
> > could well be added. However, it would complicate the semantics even
> > further. I'd really like to learn more about the requirements for that.
> >
> > Stephen, do you have any good pointers?
>
> The main motivation for having that was simply to deal with ACLs as
> sets of named ACEs, in just the same way that a file can contain a set
> of named EAs. Being able to define the namespace separately for each
> ACE in the ACL was an important property of the API I proposed, since
> it would allow you to mix both local uids and remote credentials in an
> ACL.
I have now checked Windows NT and NTFSv4 ACLs. None of NT, NTFS or Posix
ACLs are modified entry by entry; they are all replaced in their entirety
(from the point of view of the kernel). I think passing individual ACEs
separately to the kernel makes no sense.
Also, ACLs don't consist of a set of named ACEs, they consist of an
ordered vector of ACEs. At least the ACLs I know do.
Stephen, _are_ there any systems which we need to support that require
passing individual ACEs at all?
I see that we need to support other ACE namespaces in addition to uid/gid.
However, that still doesn't mean the namespace must be defined per ACE.
I'd rather we define the namespace per ACL, all ACEs being in the same
namespace. The ACL would have to be converted into one single namespace in
the kernel anyway (I assume), so there seems to be no point in mixing
namespaces at the syscall interface.
The extended attribute name would imply the namespace, like this:
EA name ACL namespace Semantics
------- ------------- ---------
system.acl uid/gid Posix ACLs
system.nfs_acl name@domain NFSv4 ACLs
[system.ntfs_acl SID's NTFS ACLs]
...
If there's an emulation from say, Posix ACLs to NFSv4 ACLs, then reading
the system.acl and system.nfs_acl both return the same ACL, once in the
uid/gid ACL namespace and once in the "name@domain" ACL namespace.
This would allow the userspace utility to work with ACLs in different
namespaces, but would greatly simplify the kernel's task of recognizing
correct ACLs and namespace conversion. The simple case would remain
simple. Mixing ACE namespaces in the same ACL simply wouldn't be
supported.
Stephen, you will likely disagree and point me at some flaw in this
design...
> > One of the issues raised was that it's important to be able to manipulate
> > multiple EA's at once. The reason for this was to reduce system call
> > overhead.
> >
> > Another idea was to allow manipulation of multiple EA's in an atomic way.
> > If I recall correctly an even stronger semantic requirement of
> > manipulating multiple EA's in a transactional way was also suggested.
>
> On-disk transactional semantics _must_ remain an implementation
> option.
Definitely so.
> > The EA_REQ_LIST operation can pass attribute names as variable length
> > records. With an integer namespace identifier the previous
> > "name1\0name2\0name3\0\0" format isn't suitable anymore, so this format
> > can be used instead:
> >
> > struct ea_entry {
> > int namespace;
> > unsigned short name_len;
> > char name[]; /* size padded to machine word size */
> > };
>
> That's "namespace" used twice. Can you be specific about this? It
> looks as if the "namespace" in your syscall corresponds more or less
> exactly with my concept of an "attribute family", and the "namespace"
> in an ea_entry with my "name family". You might want to rename these
> fields to be a little less ambiguous.
Namespace corresponds to attribute family. There is no equivalent to your
proposed name family. I was thinking that the EA syscall should return a
list of all EAs available in all namespaces (system, user, inode, etc).
> > The default semantics would be to process the requests in sequence,
> > aborting at the first request that fails. The system call itself could
> > return the number of requests processed successfully.
> >
> > EA_FLAG_ISOLATED
> > EA_FLAG_ATOMIC
> > EA_FLAG_SYNC
>
> For normal named attributes, many implementations simply will not be
> able to guarantee these ISOLATED or ATOMIC properties.
>
> For ACLs, non-isolated or non-atomic requests are completely illegal.
>
> Does it really make sense for the application to be able to specify
> these flags in so much detail in that case? I guess I agree it is
> better to specify these as options rather than to have to use a
> different attribute family to change the requested flags.
I think it's ok to allow specifying such semantics. The implementation can
still decline requests it doesn't support. Naturally, which filesystems
and namespaces support which guarantees will need to be documented in
great detail.
> > The op_flags member of individual operations could include:
> > EA_OP_FLAG_CREATE
> > The operation only succeeds if the EA doesn't exist already.
> > EA_OP_FLAG_EXISTS
> > The operation only succeeds if the EA exists already.
>
> I think things like NFSv4 don't let you do this reliably.
True. Then the kernel must decline such requests.
> The advantage of having a single "ATR_USER" attribute family is that
> you can't specify such options, so you get an API which really is a
> lowest-common-denominator which can be used by an APP without too much
> worry about the type of fs underneath.
I see this differently. User extended attributes can also support the same
flags if the underlying implementation supports it. There's no guarantee
those things will be possible everywhere, but on implementations that
support it, why not make it available?
> I just worry that making the API too flexible here is going to mean
> that applications start to develop bad habits and rely on things which
> will break over NFSv4.
There's one possible ignorant attitude towards that, and one less so. The
ignorant one is "then those applications are broken". The less ignorant
one is "then let's document these things; we can't help people who are not
reading the documentation". For some applications it will be better to
provide reduced functionality/guarantees over NFS, rather than not be able
to provide them at all, not even in the local case.
> At least, we need the implementation limitations of all of the common
> filesystems to be documented clearly in the attribute API man pages.
Yes.
> For the record, just how do you see ACLs being mapped onto this API?
> That was a point of contention in the past, but if you now see ACLs as
> being a different syscall namespace, I think we've pretty much closed
> the gaps between the proposed APIs.
There still seems to be a lot of disagreement concerning ACLs. I would
like to hear your reaction on this email, maybe that will bring us a
little further.
Cheers,
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]
