I've managed to lose the message I was going to reply to, so will do
it from memory.

Recent threads about coda's security model have been illuminating and
I now understand a few things that I didn't before.

I'd like to suggest that requirements and approaches be kept in the
source tree; right now plans and documentation seem very disjoint from
the code.

Here are some proposed security requirements, aimed at what seems not
quite right at the moment:

  high level: confidentiality and integrity of all filesystem data
  with respect to the network.

  ability to build server and client to use only reasonable encryption
  mechanisms (ifdef out xor, basically).  I know there is an
  environment variable, but security is about confidence that the
  system will behave as expected.  In my view, the quicker the xor
  support goes away completely, the better.

  ability, at least when using kerberos, to have >= 128 bits of
  strength all the way through the integrity/confidentiality process.
  (Imagine that krb5 with hw preauth leads to a 128 bit session key in
  the user->coda service ticket.)

  ability to configure servers to completely reject unauthenticated
  connections.  I realize that one role of coda is 'global
  filesystem', but I would like as an administrator to be able to turn
  this off in one place regardless of what acls get set.  This is
  partly about admin control, and partly about exposing less of the
  code to packets from unknown parties.

  callbacks go over connection with same authenticated identity as was
  used to obtain the data for which the callback is needed.  Maybe
  without connected mode we don't need nearly as many.  It seems that
  now filenames and even data can be exposed over unauthenticated
  callbacks.   So unauthenticated callbacks are only used for data
  that was fetched unauthenticated.

  not written in requirement speak: tagging of data in the cache with
  the identity whose authentication was used to fetch it, so that it
  will only be presented to that user.  (Here hashes could be used to
  avoid fetching for second user.)  The big point is that without host
  credentials, user A fetching something doesn't cause user B to be
  sure that the bits were fetched correctly.  This is particularly
  true when user A is the unauthenticated user.

  Think hard about mmap across uids.   maybe this shouldn't work at
  all, and only if uid is the same.  If that simplifies security
  model, it may be a good trade.  But maybe it's not a problem.

  Ability to make local changes to data is not negatively affected by
  sporadic network connectivity.  Once I authenticate and get data, I
  should be able to read/write it, across reboots and venus restart,
  until I get an authenticated message from the server that the access
  is revoked.   So expiring tokens, contacting server once after
  expired tokens, etc. are all not good enough.

  I really don't know about user-user isolation on clients.  If a user
  writes a file with an expired token, should another user see it?
  If one takes the view that integrity on the server is important, and
  confidentiality in transit, and that a user once authenticated has
  the unix uid bound to the coda uid until 'cunlog' time, then letting
  that change be seen isn't an integrity problem.  This is a security
  model that favors availability over the ability to revoke access
  rights, and that fits both Coda's design goals and the realities of
  what happens once you give someone some bits.

  run codasrv and venus as non-root uids in the normal case

All of this leads to making venus more of a per user service than it
is now.