Hello,

it has been quite a few times I complained... :)

http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2003/5895.html
http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2004/6191.html

The semantical inconsistency is striking me again (and again :)
so I am talking to raise the awareness of the problem.

Right now you can work
 [ connected and authenticated ]
or
 [ disconnected using the cached rights on the cached objects ].

What is missing is
 [ connected and using the cached rights on the cached objects ]

>From the security point of view it would not change a lot. If you are
sneaky, you just fool the system into going disconnected (or wait
until it is there for some reason) and access the files...

We _want_ the files to be accessible while diconnected, don't we?

As soon as we are going connected, Venus begins to insist on
checking your credentials. It is good, but has some nasty side effects,
as reconnection happens not at your will, but rather when it is possible.
So you can suddenly lose access to your files until you clog. On a flaky
network you can have problems to clog, and be unable to work as your
files will unpredictably change between being accessible or not.

I think there is no model behaviour which is bulletproof in all situations,
but I'd rather rely on the cached access rights as long as we do not
[ access a cached object AND have a valid token ],
then we would evaluate and (re)cache the rights.

That is, let the cached rights be used independently of connected/disconnected
mode, but each time the accessing process does not have a valid token
for the realm the object belongs to.

We should probably let cunlog explicitely destroy all cached rights
for the corresponding uid.

The result would be a relaxed security model, allowing stale rights to be used:
say when a user takes vacations without cunlog-ing, somebody breaks into her
account and makes changes to her cached files. Next week she comes back and
clogs, then the evil modifications reintegrate....

Still if you believe the above is unacceptable, then the current model _must_
be fixed as we have mostly the same situation, just via tricking the client
into disconnected (and we _want_ disconnected mode to exist :)

An explicit cunlog would protect the user, or we could go one step further
and let Venus remember the "last verified time" per uid and cached object,
discarding the rights when they become too old, with adjustable time limit.

I would simply use a "lazy cunlog" like "( sleep 600; cunlog ) &"
to let delayed reintegrations succeed, and then protect my cached files.
In a more paranoid mood it would be a script checking that either
the reintegrations succeeded, or time limit has been reached,
then flushing my volumes from the cache.

I understand that it can be tricky to implement reintegration logic for
such semantics. As a compromise, we could at least let read operations
follow this model, it would make life a _lot_ easier, without demanding
deep changes in the code, I think.
Possibly as a compilation/configuration option, to avoid making a definite
choice now?
Jan, would you comment?

See you!
--
Ivan