On Fri, Mar 23, 2007 at 10:21:22PM -0400, Jan Harkes wrote:
> Got it, DemoteAcRights(ANYUSER_ID) does not just drop the anyuser rights
> but all rights. A successful result from validateattrs re-establishes
> them. It shouldn't be too hard to turn that around, I guess we really
> only have to drop the rights for objects that didn't pass validation.

Tried this and it didn't work at all the way I expected (and required
quite a few changes along the way). However,

> Technically all decisions in venus should be based on the local uid and
> tokens are not really necessary. The only 'trick' is that if a user does
> not have a tokens his identity is currently mapped to an internal
> system_anyuser identity (in Realm::GetUser in venus/user.cc).
> 
> Removing this remapping for unauthenticated users should in principle
> fix both of these issues.

This actually worked exceptionally well. There were some minor issues,
making sure the rights we received from the server while unauthenticated
got correctly refreshed after re-obtaining tokens. But I've been running
it for a few days now and committed/pushed the update to CVS.

The only way cached rights are destroyed is by doing an explicit cunlog.

Any other 'invalidation' as a result of token expiry, reauthentication,
callbacks, or reconnection only marks the cached rights as suspect. We
only revalidate suspect rights if we are connected and have a valid token.

If we are disconnected or have no valid token we will use whatever
rights were last granted to this user over an authenticated connection.
If we do not have rights cached for an object and are disconnected or
unauthenticated we fall back on using system:anyuser rights.

Restarting venus allows full access to cached objects that our userid
had accessed before the restart. Same thing when a token is lost. For
the most part semantics seem sane, although there are a few cases that I
still want to test. For instance what happens when we try to access a
cached directories with an expired token (which is essentially allowed)
but the directory was updated on the servers so we can't actually fetch
the updated copy. Will we simply see the stale copy that is in the
cache, or will the failing getattr call also kill access to the cached
copy. i.e. someone may have just added a file, or maybe the ACL was
changed, there is no way for the client to tell either of these cases
apart if we don't have an authenticated connection.

Jan