u+codalist-p4pg_at_chalmers.se writes:

> It did not feel right when I had to create a fake token just to access
> my own cached files. I do shut down the computer in opposite to hybernation,
> and Venus forgets my old tokens (which is all right).

I've been complaining about this for several years.  I believe that
the relationship between local uid and coda id should be stored in RVM
and survive reboots.   It's important that one be able to explicitly
cunlog and break that, but if one is really concerned about security
one should probably also purge files that no local user has permission
to read.

> I do not see a reason why a user is forced into forging a token
> to access files. Either he/she should be denied access unless a valid token
> is presented (that would mean no disconnected mode!),
> or he/she should be allowed to access cached files which were allowed once
> during a connected session, independently of the presence of the token.

Expired tokens while disconnected allow this, so I think the bug is
that expired tokens don't persist across venus restarts.

> No security is gained otherwise (you generate a fake token easily)
> but an annoyance is created.

Plus, you can look at the cache if you have root.

> I can not log in to my environment directly, as it depends on things under
> my $HOME, so I am forced to login in two steps, first "failsafe" or on
> an alphanumeric console, forge a token, then log in as usual.
> In connected mode I am forced into doing clog the same two-step way.

I have local homedirs, and then some files in coda.  I find this is a
lot more stable.

MIT Athena had to deal with this with AFS, which had homedirs there.
There, you logged in via Kerberos and the login program did aklog
(which is like clog with kerberos).   I have long thought that Coda
should just user Kerberos and not have its own local crypto.  But, the
new RPC code with being able to get tokens via kerberos is mostly
equivalent (except that there's a lot of code and protocol that hasn't
had adequate review).

-- 
        Greg Troxel <gdt_at_ir.bbn.com>