Hello,

in the process of setting up Coda clients to be used in varying
environments (both on-campus (LAN), at home (DSL), disconnected, with
using occasional net connectivity (like modem))

I see very clearly that venus security model for cached files
should - and can - be made more consistent.

There is no other system which behaves like Coda, and there is no
(known to me) corresponding privilege granting behavior, for
the cached files. We can possibly do it a lot better than other
network-related and/or caching systems :) e.g. AFS and DFS.

<theory, a practical part see below>

Currently as long as you are disconnected, Venus uses the cached
credentials (per process uid), attached to the cached objects (or
the containing dirs?).
As long as you are connected without valid tokens, you do not have any
rights on the objects, but regain them at disconnection.

It is unknown to me when venus purges the cached uid-privileges.
Imho they should be purged for an object on
 - refetch, leaving only fetching-uid
 - modification, leaving only the modifying uid - and preventing
   acl reevaluation for other uids until this modification is accepted
   by the server
 - cunlog - if venus can easily find all objects having the cunlog-ing uid
   attached

Certainly the rights should not be purged on token invalidation!

The server's decision about token validity and acl evaluation is related
to the data on the server, while the data in the client cache was
legitimately fetched and really can/should be left available to the
corresponding uid without compromising any security.

So I do not see any need for purging uid-based access to data unless it
implies modification or fetching. No evil process can access other data
than have been fetched - or modify data on the server!

As soon as an object has been refetched or modified, we cannot any more
rely on the former server decision about the _former_ object... so no
real file sharing between users, even on the same host, could be possible
while disconnected.
It is then a clean semantics - only the once checked rights to actual
objects are taken into consideration.
If an uid had a legitimate chance to steal an object, it is already too
late to hinder (it _did_ access the object, otherwise its rights would
not be attached to that one? ok, may be the right is attached to a
directory containing the file, not the file itself (?), but still the uid
_did_ have a chance).

On the other side, NO new data can be
 - acquired from the server (you need a valid token and permissive acl)
 - snooped from others who refetch that file (fetch forces reevaluating
   your acl with the server)
 - forged so that other local uids can believe it comes from the server
   (as modification automatically excludes them from the rights until your
   changes are reintegrated)
 - ?? something evil else?

If an uid acquires a new token with a different Coda identity, it _may_
cause undesirable side effects, like unrepairable conflicts
(according to Jan and my interpretation..).

We can solve it in two rather clean and safe ways:
 - let it be the uid owner responsibility, to keep Coda identities apart
   (normally any harm will be to the files he/she has modification rights
    to, anyway)
 - assign privileges at the cached object not to an uid, but to a pair
   (uid,coda-identity)
   coda identities can be very easily forged while disconnected - but
   the only consequence would be "no rights on any object" if
   this uid never legitimately had the corresponding Coda identity.

Some protection should be made to avoid repeated retries of token
revalidation. Probably something like disconnected-mode behavior,
setting a reasonable timeout on an uid, when a token
validation fails for whatever reason (e.g. expired token).
(of course this timeout should be reset by clog)

</theory>

<practice>

On my hosts the daemons (except venus itself) are run from Coda, including
all binaries and libraries. It works fine.

 - If a computer has a good connectivity at all times, I can let it run
(i.e. access the corresponding files) by acquiring a Coda identity at the
system bootstrap and renewing the tokens at some intervals. No problem.

 - If a system is disconnected forever afterwards, it works as well, as
the cached privileges suffice...

But the problems begin as soon as you boot your system while
disconnected, or keep it disconnected for a while so that the automatic
token refresh scripts cannot compensate for the expiry...

It works as long as you are disconnected - and then suddenly collapses at
the point when you get a network connectivity.......
(I know you can run scripts at network reconfiguration, but it is
 - a hard-to-maintain workaround which has to know when and how I get a
   connection
 - just cannot really protect - the vulnerability window will exist)

Of course, the same is for the users - a bit less evident,
as their biggest problem is not the sudden changes in the connectivity,
it is the credentials expiring with the time. Imagine, this big
inconvenience would disappear too, given that they and their programs
would patiently wait until the next clog, still functioning well with the
cached part of their files!

</practice>

So, these are my several cents, pleading for a "lazy" access privilege
purging.

It would give us (system administrators) a lot of help in deploying Coda
in production, along with the possibility to efficiently use Coda's unique
features.

Thanks!
--
Ivan