On Fri, Mar 11, 2005 at 08:47:02AM +0100, Ivan Popov wrote:
> On Thu, Mar 10, 2005 at 05:53:41PM -0500, Jan Harkes wrote:
> > Actually, there is this annoying bug where a user with expired tokens
> > gets EACCESS on everything, even on those files that are accessible by
> > System:Anyuser.
> 
> I am a bit concerned about letting anyone with expired tokens
> to access things as System:Anyuser. As System:Anyuser means tokenless
> connections to the server, I may miss when my tokens expired,
> and unexpectedly lose the guarantee of server authenticity.
> I have the guarantee while I am using authenticated access (at least
> as long as nobody else fetches the objects before I do).
> 
> What we would possibly need is to mark each object in the cache
> as "fetched authenticated" vs "unauthenticated" and provide a way for a user
> to postulate "I want authenticated access _only_".
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Actually doing that might be simpler that you might think. The original
access/permission denied errors came from the fact that we actually
end up having 2 types of 'System:AnyUser'.

The first is simply a user who has never obtained tokens. Since there is
no internal user identity allocated for him, he is automatically mapped
to the system_anyuser identity. However someone with expired tokens
actually does have an existing identity, it just doesn't have valid
tokens. And because he doesn't have tokens, his connections will be
unauthenticated and the returned permissions will be identical to those
returned to system_anyuser users.

The bug was that in the place we checked permissions we checked for 'not
system_anyuser' and in the place we update them we checked for 'no valid
tokens', because of this mismatch we failed the permission check,
refetched the access rights, but didn't actually update them. So we'd
always get permission denied.

Now the question is really. Do we want to allow someone with expired
tokens to access 'system_anyuser' accessible files as long as they are
in the cache? In that case, the 'check access rights' test could be
based on whether we have valid tokens. Then if that fails, object not
cached, or we don't have rights based on the anyuser identity, we jump
into getattr which will try to get a connection to the server.

At that point we can intervene and not get an anonymous connection
unless the identity is system_anyuser (i.e. we have not had tokens).
If we are unable to establish the connection we will simply wrap back up
and end up returning an error.

The 'allow anonymous connections' test could default to something we
specify in venus.conf, and possibly be toggled on a per user basis with
a cfs command. Ofcourse cunlog should also destroy the user's identity
structure so that he falls back to being completely anonymous. I guess
an alternative implementation would be a flag that tells venus whether
to destroy the identity as soon as we learn that tokens expire and
simply never allow anonymous connections for non-system_anyuser
identities.

> Then I would be guaranteed to never fetch files (thinking, say, of
> executables) when I do not know the server autnenticity (i.e. without

True, most of the implementation seems to be whether the server trusts
the client or not while in many cases we want a similar guarantee in the
other direction (do we trust our servers). This isn't even a matter
whether people can see our traffic or not.

> tokens) and could neither unexpectedly get an object insecurely
> fetched by somebody else.

Ah, but that is something very different, that would be disallowing
_any_ anonymous connections originating from this client. In other words
you can't get anything from a server without having tokens in the first
place. But then would we allow unauthenticated users to see already
cached files as long as System:Anyuser allows them to?

I think AFS actually has a System:AuthenticatedUser acl group, which
of course can be done for Coda by creating a group that contains all
users. You just need to remember to add new users to this group.

> When using multiple computers and disconnected operation,
> bash and mozilla (or any other program unscrupulously updating $HOME/dotfiles)
> are a disaster. One may want to configure bash so that different sessions
> do not use the same .bash_history, and mozilla - for different profiles.

Or replace them with a link to a file/directory on the local disk.

> On the other side, with a bit of discipline in reintegrating, it is very
> nice to have the same mozilla setup and bookmarks everywhere :)

True, but we'd need an automatic file resolver that can make sense of
concurrent updates from multiple clients.

Jan