Coda File System

Re: Coda and RPM/tar/lchown()

From: Ivan Popov <>
Date: Thu, 28 Apr 2005 19:19:31 +0200
On Thu, Apr 28, 2005 at 10:05:39AM -0600, Patrick Walsh wrote:
> >  - 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)
> 	Here's a thought: could the kernel return ownership information
> differently to different users?  Probably.  Could it then tell the

Don't know. Jan can tell better, it can be tricky.
So the first option is in fact uncertain. Possibly not the best either.

> current user that they own all the files?  So if you go to machine A
> where your username is patrickw and uid is 833 and you clog into coda
> and ls -l you will see that you own everything.  Then if you go to
> machine B where your name is pwalsh and uid is 4001, after you clog into
> coda then you will see that pwalsh owns everything.  Another user on the

Exactly, it would be like that.
If on the second machine you name would be patrickw with uid 4001,
you would get the same output as on the first machine. But wee below.

> same machine will see different ownership.  The only question then is
> what the anonymous user sees, which could default to root/0 or also to
> their uid.

In fact, it does not matter for the user, what she sees. All users
should be aware that the "owner" does not mean anything.
The tricks are mostly for programs who check ownership - which is
a totally wrong behaviour on Coda.

One possibility to get some sence of ls output
would be to check if the process' Coda identity has read or write
rights on the corresponding object (search also, on a directory),
and fake the returned "owner access bits". Then showing the uid
of the current process as the "owner" would make some "sence".
It might improve compatibility with some broken programs which still check
the bits instead of using access().
But there is also a reverse side of the medal.

I think it would be actually _bad_ to support the illusion
that the Unix bits have sence.
New users would have hard time figuring out what of their old Unix experience
is still valid, and what is not.
It is easier to know "forget access bits, they are irrelevant, use cfs la".

So, I'd rather let stat() return root or nobody as the "owner".
It is plain wrong, but it is easy to ignore.
"Half wrong" is a lot harder to learn.

Currently it is possible to chmod() on Coda and then get the set bits
back by stat(). Good for compatibility but adds to the obscurity...
The worst (talking of obscurity) are the "advisory" owner access bits.
They send the user wrong signals and create illusions... ):

It would be a totally another and good thing to have something like
 cfs ls-l
which could possibly show a lot of metainformation,
including the "author" who updated the file last time - as the corresponding
Coda realm's account name, which is of course purely global and unambiguous.

> 	Assuming it's possible, does that fit in with the global scenario?  


Received on 2005-04-28 13:20:29