Hi Jan,

Making clear that the local uids are not used/supported in Coda
will certainly represent a step in the right direction.

Unfortunately this issue seems to be one among "the hard ones",
it looks to have been discussed on the list as long ago as in 2005.

On Wed, May 05, 2010 at 02:37:21PM -0400, Jan Harkes wrote:
> > We could let Coda always return success for chown() and always return
> > the uid of the calling process in stat(), avoiding the need to store the
>
> That is an interesting option that I hadn't even thought about. It may
> not work as well because of kernel caching and the file you are looking
> at looks as if it is owned by some user on the same system who looked at
> the same file earlier, and as such populated the inode cache.

I think you considered this approach but discarded the idea because it
is hard to implement - as you say, due to the kernel caching.

But thinking practically, the breakage because of "wrong owner" inherited
from earlier accesses by another user should not be extremely common?

User confusion is less of an issue. It is quite straightforward
to instruct the users "ignore the ownership, period" compared to
explaining when and how it could be interpreted.

There is also a couple of workarounds at hand and more can
be provided:

In the first hand one should not make such "sensitive" files stat()-able
for others. This _may_ be hard (if you for some reason must have $HOME
list-able for others, then your .ssh directory will be stat()-able) but
anyway no worse than now, actually better.

(If you have to publish the file contents for others' processes, it is
often possible to make a separate copy.)

If your file despite the efforts happens to have been tainted by someone
else's uid, most often you can "cfs fl" to get a fresh copy owned by you.
For safer use/disconnected mode a dedicated new cfs command like
"cfs own" :) telling the kernel to discard the cached metainfo might help,
wouldn't it?

(Fortunately it is still easy to implement "you own all files"
behaviour at least for the user-space-only mode.)

Even always returning 0 or local "nobody" uid would be more consistent
than the current situation. This would not help the programs checking
the ownership but would not make it worse either.
This would also reduce the user confusion.

> > Programs running as root and doing chown() on Coda and checking the result
> > do already break now, so we would hardly lose any functionality.
> 
> Right now those programs actually do work because the client allows
> chown and performs the operation locally. The problem is that the server
> will reject this 'allowed' action during reintegration if the user isn't
> a member of System:Administrators.

I am not inclined to consider programs with realm administration
privileges relying on chown() as an important (or somehow even legitimate)
usage case. The concepts of realm administration and posix-owner checking
actually contradict each other. "Owner" makes sense on old-style Posix
file systems which Coda can not be (being global) and is not.

Regards,
Rune