On Fri, Mar 11, 2005 at 03:47:34PM +0100, Ivan Popov wrote:
> On Fri, Mar 11, 2005 at 09:16:16AM -0500, Greg Troxel wrote:
> > One could use the SHA-1 hashes to avoid refetching the file, if the
> > issue is just authenticity.
> 
> Very good points!
> 
> Essentially venus should not let a user access a cached
> object unless it has verified the hash over this user's connection.

The problem is that we don't necessarily always have a hash from the
server we can rely on.

First of all the sha1 checksums aren't persistently cached on the
servers, so they are recalculated on almost every GetAttr, which was
causing some problems for our old servers when slocate started running
from ~15 clients at exactly 4 in the morning. So I actually have sha1
checksums disabled on most servers (allow_sha in server.conf).

Second, if the file was locally modified, there is no way to validate
it's authenticity until it has been sent back to the server even if the
local user had 'tokens' we don't know if those tokens are valid until
the server actually accepts the operation.

> If we explicitely disallow application of System:Anyuser rights
> when an uid does not have cached access rights, it will be safe.

That is already the case, even with expired tokens we don't fall back on
system:anyuser (ofcourse there are always exceptions, in this case we
fall back on system:anyuser permissions if we're disconnected). 

> If we'd implement another change I was pleading for
> (e.g. http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2004/6811.html)
> to avoid expiration of the cached rights at token expiry,
> then it will be convenient as well as safe!

I am still very much against this change and don't believe it is safe.
We already avoid expiration for as long as possible, only when the
server actually tells us that the token is really a useless blob of bits
do we expire the cached rights. If we don't expire then, then we would
allow operations to complete that we know cannot be reintegrated and
which would lead to a reintegration conflict.

The question is when is the most appropriate time to flush cached
rights.
Whenever the server rejects some operation? That will mostly be after
the fact, we already let the operation complete locally, why else would
we be caching rights.
When a new token is obtained? That would give the same problem we have
right now when I know I'm going to be connected for only a short period
of time, but need to get that one file. The servers will reject my
token, but I might need to reauthenticate to get access to the file.

But let's say we keep the cached rights around for as long as possible.
That opens the door to unauthorized access problems, let's say I'm
fixing something on a user's desktop with my system:administrator token.
Once I'm done, he regains his token, but he would have cached rights for
the stuff I worked on so he can change those files all he wants.
Ofcourse the server won't accept any of these changes since he doesn't
have admin rights. Unless he tricks me by creating some other problem in
another location, I come in, authenticate and poof all the unauthorized
changes just got committed on the servers.

But to validate that there aren't any unwanted operations waiting to be
reintegrated I would have to first check the CMLs for all volumes. And
since most of the problems that need admin intervention are either
repair or reintegration related it isn't useful to automatically purge
CMLs whenever I run cunlog or clog from a normal user to one with admin
rights.

Jan