[OpenAFS] Re: directories in afs have "owners"?

[Tom Fitzgerald]

> > It's not that simple. If you have 'i' access, then, as far as the 
> > server is concerned, you _can_
> > write to files whose owner matches your pts id (you might even be 
> > able to read from them - I don't remember the details). The openafs 
> > client doesn't let you open such files, but that is entirely 
> > client-side enforcement.
> 
> Hmm.. That seems... unfortunate (or at least less than secure).
> On the gripping hand, I suppose it might be challenging for the
> fileserver to differentiate a StoreData() based on an insert
> versus one based on a write....

I quite like this behavior, and wish the client wouldn't enforce
this beyond what the server does.  It lets "i" access provide
semantics like the Unix sticky bit, or windows' CREATOR OWNER
acl entry, which I've found to be extremely handy sometimes.  I
don't think I've ever used "i" with its current meaning, without
"w", in real life.

This may not be worth changing the documented semantics of "i".
(I have wished for a system:fileowner system group whose acl bits
are given to the owner of the affected file, but am not even
sure if this is implementable.)

> But it would be nice if the server could have better enforcement
> instead of the client.  What other acl limitations are actually
> only enforced on the client and not the server?

Locking is the only one I've been concerned about (the fact
that clients can release locks owned by other clients).  Since
locks are only advisory, as others have pointed out, this is
more of a possible irritation than a real problem.

And, as has been pointed out, you have to assume the client has
the rights of all the tokens it posesses, combined.  How those
rights are distributed among individual token-holding users is up
to the client.