From: Jan Harkes <jaharkes_at_cs.cmu.edu>

  On Mon, Jan 19, 2004 at 09:18:41PM -0500, Greg Troxel wrote:
  > It would be really nice if someone verified that disconnected startup
  > really worked, and that such situations survived temporary
  > reconnections even with old tokens.  IMHO, unless this all works, coda

  I'm not sure, but this patch in CVS should have fixed that particular
  problem,

      2003/11/12 16:31:40     <jaharkes_at_cs.cmu.edu>

          Persistently store realm-specific rootvolume name in the Realm
          object.

  Venus was forgetting exactly which cached volume should be mounted on
  top of /coda/<realm>. As a result it really needed to resolve the realm
  and talk to the server before it could show any files in a realm.

Sorry; I should have checked.  I only recently updated.  Indeed it
worked on my client this morning (with cvs from last week).  I must
have missed the announcement of the client RVM format change :-)
(Seriously, it would be very helpful if you were to just redist the
commit message that changes the RVM format to coda-list.)

  There is no such thing as an old token, a token can be valid or invalid
  and venus seems to allow continued access after a token transitions from
  a valid to an invalid state as long as it doesn't talk to the servers.

Well, the server rejects it after it expires, so 'old' does make
sense, but I think you are saying is that venus does not do any
checking of the date in making access control decisions, but only to
warn the user of an impending expiry (and that warning is precisely
worded, which is nice).

  Part of the problem is that there is a 'rapid cache revalidation' which
  can be used to check validity and quickly reestablish callbacks for all
  cached objects. But there is no equivalent 'rapid rights revalidation'
  which we would need to to revalidate access permissions for all objects
  when we connect to the servers with a new token.

I think the fundamental underlying need is to articulate a threat
model and concerns.  My basic point is really that with my threat
model and my needs, the current behavior is suboptimal.

  I also do not like the idea of allowing unlimited access to locally
  cached objects during disconnection to work around the token expiry /
  lack of rights revalidation. If I go home and use cunlog on my desktop,
  I do that to be sure that no-one but a local root can access files that
  are cached by venus. If full access would be allowed while disconnected
  then someone can simply unplug the network cable, possibly pass a faked
  token to venus and gain access to all my files. The only way to prevent
  that would be to flush all cached objects, which would then need to be
  refetched every morning.

Sure, I don't have a problem with this.  But note that you did
'cunlog', which is totally different.  cunlog could easily set some
RVM bits that the user is not 'active' on this machine, and thus deny
access until a server revalidation.  For those who are active (because
they got tokens which the server said was ok but have not explicitly
discarded them), different behavior is appropriate.

For instance, my notebook has good physical security.  I am totally
unconcerned with people getting root on it and getting at my cached
files.  Rather, I'm concerned with them getting at it at all, and hang
out to it carefully.   Files that I really care about I keep encrypted
(in cfs), so that getting to the server (which actually has worse
physical security than my notebooks) and backup takes doesn't get you
access to the files.

  We might end up simply creating new ways to circumvent the security
  model provided by tokens and ACLs. If that is so, we can then just as
  well simplify the whole thing by ripping all of the user, group, acl,
  authentication nonsense out of the clients and servers. (which would
  definitely make it a lot easier for first time users to install Coda)

This isn't fair, but I realize you understand this.  The security
model effectively controls (well, if it didn't use xor) access to the
server for writing/deleting, and also fetching files.  The big problem
is on multiuser machines, but in that regard coda is not much
different from regular ufs, where root can read files.  This doesn't
worry me much.

How hard would it be to replace the xor code with calls to AES from
openssl?  Really I'd like to see GSS-API wrapping, but this might be
easy enough.  I suppose we need a ciphertype, negotiation, and a way
to be sure not to negotiate down to xor (client and server config to
only allow aes).

My best thought so far is to store the uid->codaname mapping in RVM
when a token is acquired, remove it on cunlog, and use it to allow
local access (without tokens) when disconnected.  This lets the user
and root (because they can su) get at files while disconnected, unless
the user explicilty gave up access.  This also would allow us to ditch
the whole tokens-from-files bit.

People whose threat models cause them to be concerned about this will
cunlog when they suspend/logout/whatever, just as those people do
'cfs_detach' to blow their crypto keys when they logout.  (Or, they
blow the crypto keys and leave themselves access to plaintext so they
get both confidentiality and availability!)

But this might be hard or somehow contrary to the coda way.

-- 
        Greg Troxel <gdt_at_ir.bbn.com>