(Illustration by Gaich Muramatsu)
What is the design for Coda in the area of Unix file permissions? My assumption is that it's supposed to honor them, since it does in some cases. For instance, I notice that I can't chown a file whose owner is somebody else. Oh, I see in the archives that it's relying on some mix of Coda ACLs and Unix permissions. Because I recognised the potential for problems in this area, I used NIS - plus some glue code in SCM's adduser.local/deluser.local - to ensure that usernames and uids are consistent across replicas and clients, both in the Unix uid-space and the Coda uid-space. I would have expected that the Coda permissions controlled interaction between Venus and the coda server, and that the Unix permissions controlled interaction between the user and the mounted filesystem - so in disconnected mode, you might be able to make a change that's allowed by Unix permission, but rejected by ACL at the server [maybe something like this happens already when ACLs are changed at the server during disconnection?]. In connected mode, I expect the server to reject it immediately (assuming venus OK'd it based on Unix mode bits). To be specific, I believe I found two bugs that should be easily correctable: Since this file is mode -r-----, I can't open it for write, but I discover that I am allowed to chmod it. This seems like a bug to me - not owner. I have an ACL for this directory of 'rlidw'. Then there's a second bug, where only the 'owner' mode bits are tested - as if I am assumed to be the owner of the file. The test is an 'echo random-junk > filename' command, with results as described in this table: -r-------- root root filename Permission denied (OK) -r-----rw- root root filename Permission denied (BUG) -rw------- root root filename file is written (BUG) If Unix permissions are to be used at all, I'd expect them to honor these two conventions. If they're not going to be used due to uid mapping issues, that's fine by me - I'd expect this to be an attribute either of the coda-server or at the individual volume level. Probably the server. If Unix permissions aren't honored, the files could all be -rw?rw?rw?, where the x bit might be preserved and honored for convenience. chmod would then be semi-honored, and probably allowed of System:Administrators, as with chown currently (but this would only be in the Ignore-Unix-Permissions configuration). As for Windows clients... Gee, that's tougher. 9x boxes could use a static username/uid setting and access could be allowed/denied based on the Unix semantics, confusing as it might be to the uninitiated. NT-style boxes... maybe a similar setup, but with a username/uid map? I'm not familiar enough with Coda on NT to specify what the 'right way' would be in my expectation. Anyway, thanks for listening; I'll look forward to hearing about more developments in this area. RandyReceived on 2001-10-11 15:36:04