Hi,
On Thu, Oct 26, 2000 at 10:21:22PM +0200, Andreas Gruenbacher wrote:
> I'm aware of that problem. That's why I think test-and-set is less
> painfull, although it involves more overhead.
OK, I'm convinced.
> > I still think that attribute families need a different encoding so
> > that we can be really unambiguous about ACL setting and about the
> > application's expectations of inheritance, atomicity etc.
>
> I don't agree with you here. For ACLs that really require editing /
> inserting / removing ACL entries, the extended attributes interface just
> doesn't fit. A different interface to the kernel is needed for those cases
> (different system calls, whatever).
I already proposed an API which allows you to edit individual ACLs or
to replace the entire chain, in an implementation-independent manner.
And yes, it wasn't an EA API, but it could be used for both.
> I also _really_ don't like different EA families to have different
> semantics (some with atomicity some not, some with ordering some not,
> etc.) That's plain ugly with no guarantees that this more powerful
> interface will provide what's needed.
Think about the read(2) system call. Is it atomic? Well, yes for
datagram sockets, no for streams, depends on the read size for
pipes... and it's blocking or not depending on the type of the file
and the fcntl() flags you may or may not have set on it.
This is what we are talking about here --- an API which can address
different types of object in a uniform manner. The semantics are not
in the API --- they are in the object being addressed, and are hence
implied by the name you supply to identify the object. That's a
perfectly clean way of doing things which is already used extensively
in Unix.
If you go the separate-syscall approach, then you still don't fix the
problem, because:
1) you still have to deal with the fact that different filesystems
will have different semantics and so you need to add versioning/
naming control to your API anyway; and
2) the moment somebody comes up with a _new_ attribute that you hadn't
thought of, you need to resort to new syscalls or you can't access
them.
> > OK, but we _still_ need the namespace interface for authentication
> > tokens if we are to deal with things like NFSv4. That particular
> > problem isn't going to go away, unfortunately.
>
> Could you please explain that to me some more?
In NFSv4, authentication tokens are UTF/8 character strings, not Unix
uids. You can map a Unix ID to an NFSv4 name quite easily: it would
come out as "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". However, you
_also_ want to be able to deal with remote users who do not have local
unix uids, and there simply isn't a mapping between uids and those
remote names.
So, any ACL API capable of dealing with NFS ACLs must not only provide
for uids, it must also be able to accept other tokens (UTF/8 strings
in this case, but also NT SIDs in the case of SMB ACLs) if the user
demands it.
> Yes, and my position is just the opposite. I believe in keeping the EA
> interface simple
What's so complex about "name=value" pairs as provided by the ATR_USER
family? In the API I proposed, ATR_USER _is_ the basic named
attribute API. ATR_SYSTEM is the privileged named attribute API.
ATR_POSIXACL is the standard POSIX ACL API.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
