(Illustration by Gaich Muramatsu)
Hello, in the process of setting up Coda clients to be used in varying environments (both on-campus (LAN), at home (DSL), disconnected, with using occasional net connectivity (like modem)) I see very clearly that venus security model for cached files should - and can - be made more consistent. There is no other system which behaves like Coda, and there is no (known to me) corresponding privilege granting behavior, for the cached files. We can possibly do it a lot better than other network-related and/or caching systems :) e.g. AFS and DFS. <theory, a practical part see below> Currently as long as you are disconnected, Venus uses the cached credentials (per process uid), attached to the cached objects (or the containing dirs?). As long as you are connected without valid tokens, you do not have any rights on the objects, but regain them at disconnection. It is unknown to me when venus purges the cached uid-privileges. Imho they should be purged for an object on - refetch, leaving only fetching-uid - modification, leaving only the modifying uid - and preventing acl reevaluation for other uids until this modification is accepted by the server - cunlog - if venus can easily find all objects having the cunlog-ing uid attached Certainly the rights should not be purged on token invalidation! The server's decision about token validity and acl evaluation is related to the data on the server, while the data in the client cache was legitimately fetched and really can/should be left available to the corresponding uid without compromising any security. So I do not see any need for purging uid-based access to data unless it implies modification or fetching. No evil process can access other data than have been fetched - or modify data on the server! As soon as an object has been refetched or modified, we cannot any more rely on the former server decision about the _former_ object... so no real file sharing between users, even on the same host, could be possible while disconnected. It is then a clean semantics - only the once checked rights to actual objects are taken into consideration. If an uid had a legitimate chance to steal an object, it is already too late to hinder (it _did_ access the object, otherwise its rights would not be attached to that one? ok, may be the right is attached to a directory containing the file, not the file itself (?), but still the uid _did_ have a chance). On the other side, NO new data can be - acquired from the server (you need a valid token and permissive acl) - snooped from others who refetch that file (fetch forces reevaluating your acl with the server) - forged so that other local uids can believe it comes from the server (as modification automatically excludes them from the rights until your changes are reintegrated) - ?? something evil else? If an uid acquires a new token with a different Coda identity, it _may_ cause undesirable side effects, like unrepairable conflicts (according to Jan and my interpretation..). We can solve it in two rather clean and safe ways: - let it be the uid owner responsibility, to keep Coda identities apart (normally any harm will be to the files he/she has modification rights to, anyway) - assign privileges at the cached object not to an uid, but to a pair (uid,coda-identity) coda identities can be very easily forged while disconnected - but the only consequence would be "no rights on any object" if this uid never legitimately had the corresponding Coda identity. Some protection should be made to avoid repeated retries of token revalidation. Probably something like disconnected-mode behavior, setting a reasonable timeout on an uid, when a token validation fails for whatever reason (e.g. expired token). (of course this timeout should be reset by clog) </theory> <practice> On my hosts the daemons (except venus itself) are run from Coda, including all binaries and libraries. It works fine. - If a computer has a good connectivity at all times, I can let it run (i.e. access the corresponding files) by acquiring a Coda identity at the system bootstrap and renewing the tokens at some intervals. No problem. - If a system is disconnected forever afterwards, it works as well, as the cached privileges suffice... But the problems begin as soon as you boot your system while disconnected, or keep it disconnected for a while so that the automatic token refresh scripts cannot compensate for the expiry... It works as long as you are disconnected - and then suddenly collapses at the point when you get a network connectivity....... (I know you can run scripts at network reconfiguration, but it is - a hard-to-maintain workaround which has to know when and how I get a connection - just cannot really protect - the vulnerability window will exist) Of course, the same is for the users - a bit less evident, as their biggest problem is not the sudden changes in the connectivity, it is the credentials expiring with the time. Imagine, this big inconvenience would disappear too, given that they and their programs would patiently wait until the next clog, still functioning well with the cached part of their files! </practice> So, these are my several cents, pleading for a "lazy" access privilege purging. It would give us (system administrators) a lot of help in deploying Coda in production, along with the possibility to efficiently use Coda's unique features. Thanks! -- IvanReceived on 2004-03-04 08:03:01