On Thu, Apr 28, 2005 at 08:08:30AM -0600, Patrick Walsh wrote:
> the problem, but still, coda handles the chown() syscall fine, it should
> really handle the lchown() syscall the same way, even if it's broken.  

Patrick,

I do not question at all that the fix would help your users to do
what they want. Still I might possibly question that they know what they
really want - I was in a situation when I believed that a global filesystem
can usefully contain traditionally-packaged software... no more.

The change you want may be in fact a trivial additional stub in the kernel
module. It can be even not too expensive to implement like chown() is done.

Though, I am convinced that "owner"-and-friends semantics is implemented
in Coda in a non-general way and should be fully redone.
I would suggest not applying any ad-hoc fixes, but use the occation
to do it better.

The old code and semantics were chosen at the stage when Coda offered
no globality, so it was yet feasible to synchronize uids - Coda did not
cross administrative boundaries for client hosts.

Now Coda is the only really global filesystem and does what no one
did consequently before - it seamlessly works independently of the client
hosts administration. That makes the old assumptions largely irrelevant.
 
So my appeal is for the right fix instead - to redo metainformation
semantics in Coda.

> there be a config option in venus.conf that specifies a uid/gid with a
> recommended user "coda" and group "coda".  The chown() syscalls could do
> nothing and return success and any ownership lookups would return the
> uid/gid of the user and group specified in venus.conf.  

The danger is that this innocent hack in a way enforces client
host administration (right choice of the uid for _this_ client)
and has some other non-evident consequences.

One of the unique and really important features of Coda is its globalness.
What you are talking about is localization.
The same objects will look different on different hosts depending on
what the host administrator did choose.
It makes a big difference - that is no longer globality.

[I can think about several possible candidates to be presented
as the "owner uid" by stat() on Coda:

 - the running process's uid
 - the Posix superuser uid (0 aka root)
 - the usual "nobody" uid (may vary on different systems, but still has
   a common semantics)

but not a client-bound one.]

> 	But I probably don't know all the arguments and issues...

Sigh. I could not help reacting. Globalness is really a very fundamental
thing, and it is a way too easy to destroy it while reasoning in traditional
terms.

I know the difference as I do rely on globalness a lot and see the gain.

Normally no system administrator ever thinks about avoiding
host administration - it is the essence of the job, isn't it? :-)
If you analyze, you notice that the only thing that needs configuration
per (workstation) host is the login rights. With a global filesystem
all files can follow a user, not a host. It does not matter if I get
uid 1234 on one host and 87650 on another one - as long as I login as
"pin" with the same password and see the same files.

You can let login allocate uids on a host after the needs (like process ids do)
and avoid any traces of uids in your user databases, just account names
and passwords. Uids are irrelevant for making the job done.

A host is your hardware and your network connection,
so you have to make the decision about who shall use it. But that's all.

As soon as you let your host allow "pin" to login and I know
the corresponding login pass, I can use my files and programs from Coda.

Note, you do not have to configure a client host for my personal needs,
just allow me to use the hardware and the net, nothing else.

I get exactly all I need from a global filesystem without your intervention.

That scenario is possible _only_ due to globalness. For a comparison,
it is _not_ possible with AFS, if the relevant _host_ does not know in advance
about the cells where _I_ happen to store my files and programs.
Suddenly, you get a matrix of
 number-of-hosts times number-of-different-user-classes
to administrate. Just because of a little AFS (mis-)feature.

Best regards,
--
Ivan