Coda File System

Re: the protection model

From: <>
Date: Fri, 23 Mar 2007 21:34:21 +0100
On Fri, Mar 23, 2007 at 03:22:00PM -0400, Jan Harkes wrote:
> > The "lack of cache isolation" is a problem which Coda apparently inherited
> > from AFS. We should get rid of it.
> No it is inherited from the fact that the UNIX VFS layer expects UNIX
> semantics, which means that applications share the same pagecache/memory
> mappings when they open the same file.

I hope your "No" relates to my idea of the cause of the problem,
and does not mean that we shouldn't (at least try hard to) get rid of it.

I know that *nix design makes it hard, but there are approaches
which are more secure than today's cache sharing.

"The same file" is not equal to "the same name". Several processes
may sequentially open the same name and get access to different objects.

A conditional copy-on-open[*], per uid, might help - of course it would
imply deep changes in Venus, but it can be made to behave reasonably, both
from conveniency, security and *nix-kernel-compatibility view.

And of course nothing prevents full cache sharing as soon as
the client superuser says "all uids on this host fully trust eash other"
or with other words "their security contexts are equivalent"!

I still mean that the current cache sharing design has its roots in AFS
and that it could have been done and can be done more properly.

Do not misunderstand me, I have full respect to AFS, but I am convinced
that Coda can do better.

[*] Venus can always(?) pretend for the kernel that the file has been
rename()-ed and recreated since the former open(). Then it is up to Venus
to decide if it can reuse the same container file or has to make a copy or
has to fetch another copy if different uids' ideas of the contents of the same
file differ (that is, hashes fetched via different users' authenticated
connections surprisingly are different - which means server spoof - Venus
has no idea which of the users has "the right" version, but it simply isolates
them from each other). The general effect would be that caching is logically
separate for each uid. While disconnected _you_ can not use a file which
_I_ fetched, unless you also accessed the file while connected. If you modify
a file, I do not see the change until we reconnect and you reintegrate.
Again, it is easy to allow "full cooperation", and for single-user machines
it would be no change.

Received on 2007-03-23 16:35:29