Helo Jan,

> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> 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).

that's bad - but some kind of hash caching should be fixable, shouldn't it?

> 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

Say we accept the idea that a file authenticity exists per identity
(that is, different users can or can not be sure if the same file is authentic,
at the very same time). Then we must conclude that a modification of a file
destroys the authenticity for all users except the author, as the modification
may be allowed by insufficiently proven rights. Well, the file then
should become inaccessible for all other local users until reintegration.
(A sneaky user with a fake server can then try to lock out the whole cache,
but at least not achieve more the denial of service.)

Another possible policy would be to trust all authenticated connections,
but I don't think it is such a brilliant idea.
It would open possibility for attacks between local users
(I set up a faked server where I know the password and populate the cache
from it).

> local user had 'tokens' we don't know if those tokens are valid until
> the server actually accepts the operation.

Exactly. I would say "... until the server _I_trust_ actually accepts...".
So modified files can not be trusted by others than the author.

We might want something like "copy on write" and present the original
"server-authentic" copy to others until the change is reintegrated...
I guess it would be hard to do without a bigger rewrite, otherwise
it feels right. Anyone might modify files as one is allowed by her
connections, to real or rogue servers - but other users, on another
or on the same client - see the changes only after the relevant _real_
servers approve the result of the change.

On Fri, Mar 11, 2005 at 01:46:01PM -0500, Greg Troxel wrote:
> My belief is that a client with an expired token for a uid should
> behave much as if the server could not be contacted, except EACCESS
> ...

I second all of Greg's comments.

Regards,
--
Ivan