(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-12-10 11:07:02