On Mon, Jan 19, 2004 at 09:18:41PM -0500, Greg Troxel wrote:
> It would be really nice if someone verified that disconnected startup
> really worked, and that such situations survived temporary
> reconnections even with old tokens.  IMHO, unless this all works, coda

There is no such thing as an old token, a token can be valid or invalid
and venus seems to allow continued access after a token transitions from
a valid to an invalid state as long as it doesn't talk to the servers.
But that is mostly because venus has no way to check the validity and as
such doesn't realize a token is invalid without a server rejecting the
token. There is a hint embedded in the clear part of a token when the
token expires, but it cannot be relied upon simply because it is in the
clear part and can be easily forged by a user, the clock on the client
isn't necessarily correctly synchonized with the servers etc.

When a new token is given to venus, it discards cached access rights
associated with the local user-id that passed the token. This is
essential because the new token might be identifying a completely
different Coda user (f.i. System:AnyUser -> jaharkes, or jaharkes ->
codaadmin), and we want to avoid allowing access to cached, but
unreadable objects or give write permission to unwritable objects.
There are even situations where a resulting conflict is unrepairable,
f.i. a rename of a file between directories where we would need the
simultaneous write permission of both users to commit the actual
operation.

Part of the problem is that there is a 'rapid cache revalidation' which
can be used to check validity and quickly reestablish callbacks for all
cached objects. But there is no equivalent 'rapid rights revalidation'
which we would need to to revalidate access permissions for all objects
when we connect to the servers with a new token.

I also do not like the idea of allowing unlimited access to locally
cached objects during disconnection to work around the token expiry /
lack of rights revalidation. If I go home and use cunlog on my desktop,
I do that to be sure that no-one but a local root can access files that
are cached by venus. If full access would be allowed while disconnected
then someone can simply unplug the network cable, possibly pass a faked
token to venus and gain access to all my files. The only way to prevent
that would be to flush all cached objects, which would then need to be
refetched every morning.

We might end up simply creating new ways to circumvent the security
model provided by tokens and ACLs. If that is so, we can then just as
well simplify the whole thing by ripping all of the user, group, acl,
authentication nonsense out of the clients and servers. (which would
definitely make it a lot easier for first time users to install Coda)

But seriously, I agree that there is a problem in this area. It is just
that the proposed solutions just don't feel right to me.

>   My laptop can be suspended for several days without a problem and will
>   even do a suspend to disk if the battery is almost completely drained.
...
> But surely your machine crashes occasionally, or your battery runs
> down, etc.  That you are getting away with this is nice, but it isn't
> a general solution for all usage patterns.  Before realms, this used
> to work.  Now, I think the realms resolution needs to happen before
> coda is usable at all.

I'm not sure, but this patch in CVS should have fixed that particular
problem,

    2003/11/12 16:31:40     <jaharkes_at_cs.cmu.edu>

        Persistently store realm-specific rootvolume name in the Realm
	object.

Venus was forgetting exactly which cached volume should be mounted on
top of /coda/<realm>. As a result it really needed to resolve the realm
and talk to the server before it could show any files in a realm.

Jan