Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> On Tue, Mar 20, 2007 at 10:33:11AM +0100, Enrico Weigelt wrote:
>> how can I get write access to my coda files in disconnected mode ?
>> 
>> If I authenticated while online and then disconnected, it seems to
>> work somehow, but the client must not have been rebooted for that.
>
> This is an argument that has been ongoing for a while. Only a server can
> really validate if a user has write permission, the client caches some
> of this information to avoid having to pass every request to the server
> and to survive during disconnections.

I think it's useful to really think about the requirements and use
cases for a system like coda, and to question whether the current
approach really serves the needs.

Regardless of single/multiuser, I think disconnection should be as
transparent as possible.  Of course some things won't be in the cache,
either files or acls.

In my use case, I would like:

  tokens are not needed for local operations

  mapping of unix uid to authenticated user is retained unless I do
  cunlog explicitly, even across system reboots and venus restarts

  acls or whatever is needed to choose to allow read/write is
  retained, even across restarts

  a brief reconnect/disconnect does not really change anything, unless
  we find out from the server that an acl has changed, in which case
  sure we can follow the new rules

I think this implies that destroying all cached credentials on a
reconnect is not reasoonable.  Doing some sort of validation of them,
like we revalidate cached file objects, would be reasonable.

Perhaps it would be useful to state needed security properties.  Once
you've let someone read something, they migth well have copied it, so
trying to purge acls from caches seems like not a lot of gain, and it
can cause great trouble for users with flaky connectivity.

A larger plan for a richer "what's changed" summary from servers on
client reconnection would help; right now the client seems to assume
that files might be different and revalidates on access if connected.
In addition to sending a "here is the list of cache invalidations
since we last spoke", a similar list of acl invalidations could be
sent.

But, all in all, I'd rather have the client keep the acls and risk
continued access in the event of acl change rather than deny access
when needed.  If I can't count on coda to let me at my bits when the
net is flaky, it fails at what I consider it's main mission.

Note that someone could change venus on their box to bypass all acl
checks anyway.  So we're only arguing about the default behavior seen
by people who aren't trying to cheat.

I realize this is controversial, so perhaps a venus config flag to
control the behavior is in order.