Hi Patrick,

On Wed, Apr 13, 2005 at 10:55:57AM -0600, Patrick Walsh wrote:
> # cfs la /coda/myrealm
>       System:AnyUser  rl
> System:Administrators  rlidwka
> # ctokens
> Tokens held by the Cache Manager for root:
>     @myrealm
>         Not Authenticated
> # ls /coda/myrealm
> ls: /coda/myrealm/: Permission denied
> 
> 	If I authenticate as a user, I can view everything properly.  So it

it's one of side effects of "to-be-fixed" controversial behaviour
when an uid's authentication state changes (say your tokens expire
or you do cunlog or you clog as another Coda identity).

Your uid has most certainly been used as an authenticated user,
and Venus does not handle "properly" the change to unauthenticated.
I see it as a useful feature, as otherwise you might be possibly
unconsciously using anonymous insecure access when you believe you have
tokens (and hence are protected against server spoofing).

It will be fixed, but for now let you test anonymous access from another uid,
which you never do clog from.

It is anyway not a good idea to use the same uid on a host for different
identities in the same realm - that way you mix security domains.
Coda identities are totally isolated from each other - but all rights
on a Unix client are associated with an uid, and as such would overlap both
Coda identities. It is hard (if possible at all) to handle such situations
and keep the access semantics intact.

Note that you can have tokens for different identities in _different_ realms,
at the same time, it is of course totally ok - it causes no semantical
problems, the uid's rights are the plain sum of the rights in the realms.
In contrast, it is undefined how to "sum" rights of two identities in the
same realm, there is no support for such operation. Each action on objects
in Coda is done with one sole identity. In unix you want a separate uid
for each identity to make sure they do not (possibly badly) interact.

I do not say your particular case can not work - it could - given some fixes
and also some constraints which are possibly not trivial.

Cheers,
--
Ivan