(Illustration by Gaich Muramatsu)
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, -- IvanReceived on 2005-03-11 12:05:23