(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-02-22 11:51:07