On Tue, Dec 09, 2003 at 10:57:36AM -0500, Ivan Popov wrote:
> At the moment venus notices that the server is available after
> disconnection, it tries to verify the available user tokens and
> reintegrate the changes.

We do not really 'verify' the tokens.

What happens is that venus detects that the server is up and running,
and then either reintegration is triggered to run in the background, or
the user performs some action which requires us to talk to the server.

Now we try to set up an authenticated binding to the server, using the
token associated with the local userid. The server rejects the binding,
telling us that this user in fact does not have a (valid) identity as
claimed by the token, and the client does a forced cunlog, which kills
all (local user id, coda rights) information.

The operation is then retried, and because the user doesn't have a token
the new connection will be for System:AnyUser and if System:AnyUser is
allowed to perform the operation it succeeds, otherwise we return
'permission denied'.

Now I do have problems with this whole thing,

If we keep the token around, then operations will keep retrying and get
rejected all the time. Every operation would time-out after N attempts
with an EWOULDBLOCK error until the user acquires a new token. This
makes the system unusable during connections and probably counters the
whole point which is to quickly fetch some file when briefly connected.

We could drop the token, but not the rights. This would mean that the
user has a System:AnyUser identity but keep access permissions according
to the old (proven invalid) identity. I don't think this is necessarily
a good thing.
    
We could in the 'connected case' ignore the local uid if the user
doesn't have a token and when disconnected start using the local uid
again. Strange semantics, but it can work. So we clearly can kind of
work around it so that a user with an expired token can both access
uncached files that are accessible by System:AnyUser and regain access
to locally cached files _once we become disconnected again_.

But there is a whole other issues when a user acquires a new token...
As far as the client is concerned this is an as yet unproven identity
and it has to drop locally cached access rights. In fact it is not
completely unusual to switch identities. Sometimes a user has a conflict
that he cannot repair due to the ACLs, but I can log in with an
administrator token to fix the problem.

So whatever rights our local user id has before a clog might not match
the rights after the clog and we can only tell by checking everything
against the server. There is special rapid 'cache-validation' to check
freshness of cached files with ValidateVols and ValidateAttrs RPCs, but
there are no equivalent RPC calls to rapidly check rights. We have to
perform a getattr on every object to re-cache access rights for the new
identity of the user.

Jan