On Thu, 26 Oct 2000, Stephen C. Tweedie wrote:
> 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 would like to research whether a versioning interface (to ensure
consistent updates) is possible at all, so I will take a closer look at
the NFSv4 spec.
> > > 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.
You have the same operations on files, and usually, you get to choose the
semantics yourself (as the user of the API). In the EA case, the semantics
would mostly be enforced by the kernel, depending on the EA name.
> 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.
The moment somebody comes up with a new system EA, that somebody will have
to implement the right policy in the kernel (as an EA handler in my
implementation). System EAs are not just EAs that happen to have a
different name. Manipulations of them are tightly controlled by the
kernel.
User EAs have clearly defined, consistent semantics across the user part
of the namespace, so adding new user EAs of course does not require
anything like that.
> > > 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.
There seems to be a fundamental problem here. You are talking about
manipulating ACLs through the kernel interface that have no meaning to the
kernel itself. The kernel just doesn't know anything about
"[EMAIL PROTECTED]", not even for the local domain. The kernel also
can't even translate from username to uid. It knows only about uid's;
that's what access control decisions are based on. The Posix ACLs I have
implemented are meaningful to the kernel, so the kernel can deal with
them.
I have to do some backgroud reading on NFSv4, but right now I really don't
know what the kernel could ever do with "[EMAIL PROTECTED]" other than
pass that on in an NFS RPC or such. Imagine if the kernel did store
"[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control
decision needs to be done, the kernel simply has no idea about what
"[EMAIL PROTECTED]" means.
> > 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.
It's that in your proposed ACL namespace you have vastly differing
semantics, differing operations, in fact, a completely different API. The
user/system/privileged namespace has simple EA semantics, while the ACL
namespace is a world by itself.
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]
