> 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.

I did not think _at_all_ about fetching. If you are going to fetch
something consciously, you can clog as well. Otherwise you can not - as
your rights expired. No problem.

I am concerned about _cached_ objects that suddenly become prohibited
after a casual connection.

> 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.

For me it sounds unclear, what the access rights evaluation would look
like.
I'd rather think about an "unverified" Coda identity that does not
disappear even because of provenly wrong token. Let each
uid freely pretend being anyone in Coda, just do not believe it for
granted.

> 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

Think I have a program creating small files with output data in my
Coda homedir. A week disconnected, halfway into the computations...

Now when I am inserting a network card and get connectivity, the program
gets permission denied and dies... before I realize the danger and clog or
disconnect... That is a problem.

Another effect is that all my programs (hah... including clog :)
become inaccessible at reconnect if my tokens had expired. Oh no!

I'd like to keep my cached rights until I prove my identity again.
No security loss, as no server-side information is concerned, and I had
all my disconnected time to try to abuse Venus and the rights :)
See you, while disconnected I _can_ successfully pretend being anyone - but
have no cached rights, nor any way to acquire them.

> 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_.

It would still not protect the running - and dying - processes,
losing the rights to their libraries (!), config files, and so on.

> 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

Ok, I could accept loosing the old rights if I made a decision to clog.

> 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.

As said, I could live with that. Dangerous when I clog on flaky network
and then loose most of my cached rights - but at least I can decide if I
take the risk.

Then, we could cache the coda identity along with access rights, and
purge them / ignore them only at the access when the cached identity for
the uid is not the same as the uid's current one.

Forging Coda identity while disconnected would not help, as it is the uid
which has the rights. Confirming Coda identity while connected would not
invalidate all cached rights, while changing it _would_ prevent using the
old rights.

[As potentially acls could contain global (not realm-local) identities,
we can be forced into caching the combination of the uid's identities used
together with the object's acl, which led to the cached rights.]

Then, if the uid still [pretends to] have all of the identities, then the
cached rights should be used if disconnected or without a
token (reevaluated and recached if connected _and_ having a valid token!).

Otherwise the cached rights could be ignored, but they do not have to be
dropped - in case a user decides to change her role and will pretend to be
again the same identity combination as at the beginning.

In that case, an uid can be present several times among cached access
rights, each time with different corresponding "Coda identities set".

Does it sound reasonable? Doable?

I am thinking about a user who forgets to clog and is working 30 hours at
her workstation, fully connected. Then after 25 hours she would be
logically disconnected at tokens expiry but could continue working, her
changes of the last 5 hours would be reintegrated next morning when she
logs in and acquires tokens...

Right now I am experiencing rather different situation
(on DFS but almost the same) : my pine begins complaining about
unavailable files! Luckily I know to suspend it and can run "kinit" to
renew my DFS credentials - but it is hard for a less technical user.
As a sysadm I'd welcome "disconnection" behavior - it would also let
people with long computations to start them and let run without token
renewal, even for weeks, in most cases!

Regards,
--
Ivan