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,
--
Ivan