On Thu, Sep 04, 2003 at 11:17:58PM -0400, Samir Patel wrote:
> Something I noticed while playing around with coda today:
> 
> Say user A borrows user B's laptop to modify some files in user A's
> home directory.  Also assume that user B shouldn't have access to user
> A's files.
> 
> 1) User A logs into a dummy local account, authenticates to Coda and
> creates/changes files.
> 2) User A unauthenticates..
> 3) User A gives laptop back to user B.
> 4) User B becomes root.
> 5) User B now has access to all the files in Coda that user A modified
> and changed.

Not really. Coda doesn't care user B is logged in as root. If root
doesn't have the right ACLs the only recourse for user B would be to
directly modify the container files in the venus cache directory. If he
modifies those the files will not be marked as 'dirty' unless user B
actually changes bits around in RVM (which will probably lead to a
crash if he forgets to link the faked CMLs correctly).

I didn't think that disconnection should allow user B to even read
any files that are protected by an ACL that doesn't allow System:AnyUser
read access to the object.

> 7) Now if user A borrows user B's laptop again, his Coda directory
> will be in the disconnected state and he will be unable to do anything
> about it (I think).  If he creates tokens as root, all the changes
> that user B made (which user A does not allow or condone)  will
> propogate back to coda.

If someone gets an 'untrusted' laptop you can check the state of
(important) volumes for pending CML entries for your userid before
obtaining tokens. Besides user A probably should not have root access to
user B's laptop and _never_ get tokens for the root user. It used to be
that Coda explicitly denied the root user from obtaining tokens.

This is the no different from user A and B logging on with the same
user-id at the same time and A obtaining tokens while B is modifying
files.

Jan