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.

Randy