Hi Enrico and Jan,

> 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 ?

There are several sides of the problem.

There is no consensus about the desired semantics to be seen by the user.
Different ones may be necessary for different scenarios, like
 single user laptop
 several cooperating users, fully trusting each other
 multiple independent users

A host most often can be forced into disconnected mode by external means
(either physically disconnecting or flooding the client or the servers)
As such, system security is not allowed to depend on connectivity, it is never
better than in the weakest mode.

While disconnected there is yet no conveniency, nor security.

The current code tries to enforce some access limitations on the client side,
which is quite pointless looking at Coda security model - trusted servers,
unreliable clients. Anyone can go past such limitations on her own client.

At the same time protection between different uids on the same host is
broken, which eventually opens for the users a possibility to impersonate
each other on multiuser Coda clients.

An additional dimension of the problem comes from the OS kernel.
*nix kernels are designed so that as soon a process opens a file,
the contents is supposed to be shared with other processes open()-ing
the same name (Jan pointed out this implementation problem to me).
That is fundamentally incompatible with disconnected mode where we can
e.g. never know whether a change is legitimate, until we ask a server.

> Coda used to agressively discard all cached rights when tokens expired,
> or when the client was restarted. Very annoying for disconnected users
> as they had to reconnect, authenticate and re-hoard to recache their
> permissions.

An example of especially harmful client-side authorization.
Good that there is some progress there.

> access to your files. However once you reconnect and the token is deemed
> invalid all cached rights are immediately revoked and if you then
> disconnect the token would be useless since we don't have access to
> cached rights anymore. Also if you should have access to some object,
> but another user fetched it during the connected period but your
> identity has not accessed it until the client got disconnected  there is
> no cached information that states that you actually do have read or
> write permission.

If each user had her own file cache, such cached permissions
would be not necessary, except as a hint (do not modify this file,
the change will be most probably rejected by the server).

Even for multiple users, proper (secure) cache sharing could be implemented,
at least for read access (see above about *nix write sharing semantics).
That is unfortunately not how it works now.

> Then there is the argument for single user clients to never bother
> checking cached rights, so we'd have read/write access to anything and
> the server will simply prevent us from reintegrating anything we don't
> have permissions for. This is very useful for a single user client, but

That would be equally useful for a multiuser client, as long as all
modifications are isolated to the uid who did the modification,
i.e. invisible to the other users until checked with the server.

Rights for disconnected reading should of course depend on the fact that
the given uid _did_ indeed fetch the file or its hash from the server
(and the file contents was exactly the same as when fetched by other uids!) -
in contrast to caching acls-evaluation/alike it protects against
[omitting a description of a relatively simple attack].
This condition essentially describes the only situation when cache sharing
is safe.

Coming back to the topic - the inconveniences while disconnected do not
in fact have any good reason.

In my eyes, even expiring tokens in general should not prevent users
from accessing the cached objects, nor modifications.
That should of course work the same with fully available network (security
may not depend on connectivity). I'd like to notice when my modifications
cease to propagate, but that's all. I may choose to authenticate a week later
and until then behave like in disconnected mode, why not?

Such (quite logical and secure) change would make Coda
a lot more friendly to the users.

Again, security and conveniency do not contradict each other,
it is the irrationality of client-side authorization which harms them both.

Best regards,
Rune