(Illustration by Gaich Muramatsu)
Hello, I am thinking about the semantics of some meta-information that Coda maintains. Neither file owner nor access bits are used for the decisions about granting access to a file. This information is used (and wrongly relied upon) by some programs assuming Unix semantics. It creates also misunderstanding by the new users and administrators who have to learn, sometimes the hard way, that the owner and the modebits are not relevant at all. The current practice is keeping and presenting any information set by create(), chown() and chmod(), while it is essentially incorrect. File creator id could be useful in some contexts on its own, but it cannot be presented correctly, as Coda does not enforce synchronization between its internal uids and client-side OS uids. In the general case it is *impossible* to synchronize uids as some OSs can lack the concept of an uid or say insist on using huge world-unique uids. With other words, trying to map server-side Coda uids to client-side local OS uids is just a hack that can work on smaller installations but is deemed to problems and "impossibilities" in the long run. Nowadays Coda becomes a global filesystem, allowing access to multiple realms. The same client can talk to different realms with totally independent Coda uid assignments. It can be a better illustration for the fact that synchronization between Coda uids and the client-side ones is inherently impossible. So I question whether we should even *try* to do such mapping - that is going to be wrong pretty soon. I see the following needs that we may want to address: #1. give hints to *nix-inspired programs about access rights on a fs object, when they are looking at the owner uid and the mode bits (they are doing wrong, but we can't fix it) #2. give hints to a human (or a script) about who has been the creator of an object - what "ls -l" uses is the owner id and passwd name service What is the best approach / approximation? One possible approach would be to stat() as done by venus: if( file_owner_coda_id == process_coda_id ) return process_uid_and_generated_mode_bits [*] else return client_os_superuser_id_and_generated_mode_bits [**] [*] as we show file owner id being the same as the uid of the process doing stat() and as we can set access bits according to the actual process rights, stat() would work similar to access() and hence give the "right" result For a nice-looking group bits approximation we could reserve a group id like System:Administrators to *not* affect the generated group bits, but any other acl entry (granting access) to cause corresponding group bits to "look set", "look unset" otherwise, (it would play nice with the current practice of returning a suitable "nogroup" group, even better when it is possible to reserve and use a "some_group" group id on the client side) [**] we can show file gid equal to the requesting process gid and set group bits according to process rights, showing some default value for the "root" owner bits "other" bits can naturally show the anonymous access status of the object chmod() would have to be a no-op. chown() cannot be "correctly" implemented given that *nix uid is not generally mappable to the Coda one. I would suggest setting file "owner" at write() operations instead - at that time we have the Coda uid at hand, and this information is quite relevant if we want to know who is responsible for the file contents. I think it corresponds to the intuitive notion of "an owner". ------------------- The semantics of "execute" permission on files is not very meaningful for remote ones - there can be no execution without read rights. This bit is neither reliable for preventing execution of a file, in the general case. Still sometimes this flag can be useful as a hint (?) We could let chmod() set the x-bits, and mask them at stat() time by ~(the generated read bits). But then it inevitably causes extra headaches... a simple and reliable solution would be to just synchronize generated r and x bits. ------------------- There are certainly other possible approximations, but I suppose that generating this kind of meta-information instead of storing it is the only feasible way to remove the inherent logical problems - like "ls -l" displaying unsuitable account names and get rid of unnecessary headaches - like repairing conflicts that differ by mode bits... the above would solve [#1] and partly even [#2]. Such approach would make understanding of the access granting logic easier, traditional programs more robust on Coda and it would prevent users from playing with chmod and assuming that it helps. Optional: --------- For the purposes of [2] we might provide something like "cfs ls-l" that would generate ls-like output but translate uids to account names internally, not via the client side naming service - that will be the "right" creator information, also including the realm: -rw-r--r-- 1 chalmers.se:pin some_group 1143 Nov 20 10:04 \ /coda/chalmers.se/mine/example -rw-r--r-- 1 other.place:pin some_group 1143 Nov 20 10:04 \ /coda/other.place/anotherperson/test unsure if we want "ls output format" compatibility, rather not, bare "cfs showuser" would be much cleaner: $ cfs shu mine/example anotherperson/test chalmers.se pin mine/example [*] other.place pin anotherperson/test [**] [*] user_at_realm while being a "natural" notation would look like mailaddress, still completely unrelated, and would be harder to parse in scripts [**] you see, the first "pin" is myself, while the second "pin" not at all, I just happen to look at his files My 2c, -- IvanReceived on 2003-04-06 18:58:19