I think it is a good idea to step back and look at requirements:

  A user can run munged venus code if he wants, so checks in venus are
  necessarily of limited value.

  We should think of venus-performed checks as having utility limited
  to the timesharing case where separate users both to a venus and we
  desire venus to maintain access control of one user and the other's
  files.  This is of course the normal case on most Unix-like systems.

  A server should only allow reads/writes to an actually authenticated
  user.  This is pretty straightforward and I think currently true.
  But probably sftp transfers in process should be aborted when doing
  cunlog.  I try to do that when venus hoards a huge file at an
  inconvenient time to tie up the modem for an hour and end up having
  to kill/restart venus and not clog until I can spare the capacity.

  Availability (read and write) when offline is very important for coda,
  in terms of being IMHO the major justification for using coda instead
  of afs.  (I realize it is more complex than that, but that's how I see
  it relative to my needs.)  A disconnected user should be able to
  access cache files if at all possible.

  On my notebook, for files my uid got from the server, there is no
  reason for venus to not let me read/write them, even if I have not
  clog'd in a month and venus got a chance to talk to the server.
  The only exception is if I have explicitly requested that the files
  be unavailable.  And if want that, I probably want to zeroize the
  cache, too.

With that in mind, I'll assert

  A token represents the right to read/write files _from a server_ for
  a defined period of time.  This is fine, and if one assumes that
  server access and the ability to get tokens go together, this is a
  reasonable situation.  Note that this means servers which might be
  traveling with users then need to be authentication servers too.

  Access control at the user/venus boundary is really a separate
  issue.  Venus could record the unix uid/coda user mapping from
  getting tokens, and allow access based upon the uid for items in the
  cache.  If the acls are cached with the directory, then these
  decisions can be made.

  Merely reconnecting temporarily should not start requiring tokens.
  If I plug my notebook in for a minute to do something else and venus
  talks to a server, but I'm not paying attention, and then I go off
  somewhere and try to get at my files and find that my privileges
  have expired because of this, I'm going to be grumpy.

  An explicit cunlog could remove the unix/coda uid binding.  Thus _if
  one trusts venus_, this can prevent others on a system from getting
  at your files by getting your uid.  But this is kind of silly, since
  then they can probably read the venus cache directly.

  A further option could be 'flush files from cache that no other
  uuid/cuid binding has a right to read'.  I recently got a
  rescued-on-the-way-to-the-dumpster Sparc Classic.  It has Solaris on
  it, with an AFS cache with files in it.  I wonder whose, and what?
  The proposed option is intended to avoid this sort of problem.

Right now I have a script to get tokens which always invokes -tofile,
so I can put them back if I have to.  But I consider this kludgy.

In summary, I think I'm arguing for an indefinite-life binding between
uuid and cuid for files already in the venus cache - one that survives
restarting venus.  This is security-wise analogous to copying files
from /coda into a regular UFS filesystem, where one doesn't need
authentication to read ones own files (or rather, that's what login is
about, and having a uid is the equivalent of a token).