(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-09-05 12:35:16