Coda File System

Re: Next 3 questions

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 22 Feb 2002 11:51:04 -0500
On Fri, Feb 22, 2002 at 02:18:23PM +0100, Ivan Popov wrote:
> On Thu, 21 Feb 2002, Jan Harkes wrote:
> > So if local user 'billg' does a clog with my Coda-token in disconnected
> > mode, he still does not gain any access to my files because the objects
> > have only stored that they are accessible by the local user 'jaharkes'.
> 
> How is it with cached objects accessed by several users
> (like program binaries or shared documents)?
> If "anyuser" accessible objects remain accessible for all but not
> otherwise, then it looks pretty acceptable.

I was looking at the code yesterday, and it looks like there might be
some not eally consistent handling in all cases right now. I believe
there are some bad 'optimizations' that can be used to circumvent the
access policies. For instance, token expiry (and thus cunlog) only mark
the access state as requiring revalidation. Validatevols/attrs
reactivates cached permissions when the object hasn't changed. I can
pretty much see the situation where someone does 'cunlog', the client
disconnectes and reconnects, volume-validation succeeds and if the
client is then disconnected before accessing any objects access is
'regained' as if the user never discarded his token.

It also looks like an authenticated users will not be matched against
the System:AnyUser mask, which I believe is wrong. Your description does
match the intent. An access check will return both the Anyuser and the
checking user's access permissions.

> I would like also to understand what happens when two users on the same
> disconnected client access files belonging to one of them, if the other
> has the rights set explicitely by the acls (per user or per group).
> Will the second user be excluded during disconnect?
> Will the owner be able to access the files if it was the other who fetched
> them into the cache?

Yes the second user will be excluded, and no it doesn't matter whether
he is the 'owner' or not. Because user/group relations can be pretty
complex a client would otherwise have to have it's own copy of the user
and group database as well as having a way of reliably proving the Coda
identify of local users (or groups). This requires access to 'private'
server information such as the password database and the authentication
token. But clients are considered 'untrusted', so only servers get to
see this information and they are the ones that make the decisions.

If an object is cached, but accessibility for this object by the
requesting user is not, there is an RPC that does nothing but the access
check. Every object has a small but fixed 'cache' of the access rights
of the last 6 people that tried to access the object to avoid doing
these checks too often and to gain a reasonable chance that any required
permissions are cached during disconnection.

Jan
Received on 2002-02-22 11:51:07