Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> The question is when is the most appropriate time to flush cached
> rights.
> Whenever the server rejects some operation? That will mostly be after
> the fact, we already let the operation complete locally, why else would
> we be caching rights.
> When a new token is obtained? That would give the same problem we have
> right now when I know I'm going to be connected for only a short period
> of time, but need to get that one file. The servers will reject my
> token, but I might need to reauthenticate to get access to the file.

My belief is that a client with an expired token for a uid should
behave much as if the server could not be contacted, except EACCESS
for new things instead of ETIMEDOUT.

> But let's say we keep the cached rights around for as long as possible.
> That opens the door to unauthorized access problems, let's say I'm
> fixing something on a user's desktop with my system:administrator token.

Did you use the admin token with the user's uid?   That seems like a
bad thing to do - any process the user had left running could then use it.

> Once I'm done, he regains his token, but he would have cached rights for
> the stuff I worked on so he can change those files all he wants.

You should do an explicit cunlog, which should dissociate the uid and
any cached rights for that coda user.

I don't see the "changes we can't reintegrate" problem for expired
tokens.  Yes, not yet, but someone who had a token can probably get
one again.

This raises the ugly issue of disconnected operation (or expired-token
operation) on machine with two uids, each mapped to a different user.
Should such users see each other's changes?

I'm often flakily connected (ad hoc networks).  To go from being able
to use my cached files to not because of a few packets back from the
server is really a bad thing, and if I understand right that's what
happens.

It would be nice to have a gnome panel applet that shows connection
state and token state; that would alert users to expired tokens and
enable them to freshen them.   This would avoid part of the motivation
for wanting to fail operations with expired tokens when the server has
been heard from.


-- 
        Greg Troxel <gdt_at_ir.bbn.com>