On Fri, Mar 11, 2005 at 10:50:47AM -0500, Jan Harkes wrote:
> > to postulate "I want authenticated access _only_".
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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.

That is was what I want to avoid, automagical unauthenticated connections...
 
> refetched the access rights, but didn't actually update them. So we'd
> always get permission denied.

I agree the check does not have much sence,
but the resulting decision is safer than otherwise!

> 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?

No. In my eyes it is a wrong check. We should not depend on acessibility
for 'system_anyuser' on itself, as we never know if these rights are
real or faked by a rogue server.

We _can_ go after accessibility for 'system_anyuser' _iff_ we know
these rights were fetched over a connection established at some point
with current user identity's token - that means "proved enough for this user"!
But then (I suggest) we should go rather after the fetched rights for
_this_ user identity at that time, which is exactly _as_ valid as the
then fetched 'system_anyuser' rights! and makes more sence :)

> The 'allow anonymous connections' test could default to something we
> specify in venus.conf, and possibly be toggled on a per user basis with

I do not see a real reason to use anonymous connections for non-anyuser
identities. Such connections are mostly conveniency measure, giving the users
with stale tokens some kind of access. It would be more convenient to apply
the old rights to the cached objects... and it would be safer as well.

One scenario that suffers a bit without the anonymous fallback is
a mostly readonly site where the users do not care to authenticate.
No problem, as long as they do not authenticate - or run cunlog,
they are "fine".

> a cfs command. Ofcourse cunlog should also destroy the user's identity
> structure so that he falls back to being completely anonymous. I guess

Yes.

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

No, not that! Any unauthenticated user can fetch some file anonymously, 
while I couldn't access it with expired tokens. When I access it with valid
tokens, the file hash as well as my rights get verified with the server
and my access rights are remebered for the cached file.
Next time I access it without valid tokens, I am allowed (as well as anonymous
users, of course, who get their rights cached along with this object all the
time), but not another user with expired tokens, unless it has been here while
the tokens vere verifiable.

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

No, not that either. A real server can force all users into authenticating,
while a rogue one will happily allow them to access troyan data.
That is, user presense in a certain group is checked on the server side
and as such does not buy anything if you are unsure about the server.
To disallow unauthenticated connections on _all_ _clients_ in the world would
help, but then we would have to also run something like a public key
based "public tokens" granting service.
I did that, and it works, but it alone does not solve all issues, like
"proved enough for _this_ user"...

Regards,
--
Ivan