Hi Jan,

glad your reply sounds positive.

On Fri, Mar 23, 2007 at 11:00:46PM -0400, Jan Harkes wrote:
> Actually as of 6.9.0 this may just be possible, we refuse to reintegrate
> without tokens, but we could still access cached object based on rights
> we had before the token expired. Any uncached objects fetched during
> this period would get system:anyuser rights.

These are the unsecure anonymously fetched objects. They are
in general dangerous and imho shouldn't be made available to any user who does
not explicitely request them (e.g. by doing a clog to some reserved Coda uid
which does not talk to the servers but creates a pseudo-token locally).

Anyway, it is important that token expiration should _not_ replace
the user's authenticated connections with unauthenticated ones, as
it opens a good possibility for a spoof attack, when a user may believe
she is protected. "Connection timeout" is suitable, but defintely not a silent
anonymous fetch.

> only problem is that currently rights are reinstated when validateattrs
> reports that an object has not changed on the server, which is actually
> really bad if the user had an administrator token and switched to a
> normal user identity. I think the only other way to recache rights is to

Switching between different Coda identities for the same uid
is a very controversial practice. I think it is impossible to support
it "properly" as it makes security domains / contexts overlap
and to be consequent we really should treat them as equivalent ones
thereafter.

I mean that if my user account/uid has certain security level and I give it
rights to some files or areas by clog-ing to an admin identity,
those files and areas are protected no more than my user account.
Possible later invalidation of these extended rights limits the time window
of possible damage but security is already breached and the files
may have been modified by an evil process running as the uid in question.

That's why I would say that a best practice is to use different uids
for different identities (that's what I do myself of course)
and not spend developers' efforts and/or sacrifice security
for the sake of convenient but flawed practices.

> Also keep cached rights demotion when a server rejects our token, Greg's
> argument is correct, if we already had an object cached we could just as
> well have copied it to the local disk, or search for it in the cache
> directory. These changes should make reconnections and token expiry a
> lot more liveable.

Good.

> Then there still is the issue of PromoteAcRights, which I still find
> highly suspect, but it may be needed because I don't really see any
> other way in which we currently (efficiently) reestablish our cached
> access rights. Maybe clog and cunlog need a more agressive method to
> clear out cached rights so that they will not be reestablished by
> PromoteAcRights.

If I understand you right, it is the issue of limiting the (already done)
damage because of switching the network identities.
In fact, I wouldn't care. The reestablishment of the rights seems to be
consequent from the security viewpoint.
Those who mix security contexts should accept the consequences :)

A workaround might be an explicit cunlog from the admin identity, which
might clean up all associated cached rights.
This does not have to be a task for the revalidation code, doesn't it?

Best regards,
Rune