Hello Jan,

On Wed, May 05, 2010 at 11:48:37AM -0400, Jan Harkes wrote:
> So maybe in the long run it should just be in Coda's best interest to
> start _completely_ ignoring user id values. We already mostly ignore

I am so glad you say this.
(didn't we talk about it already years ago? :)

> modebits, only owner 'r--' bits are interpreted as overriding the write
> directory acl

(Implemented on the client side - as such being a safety net defending
from oneself only, not providing protection from an attacker. Imho it
should be documented with a warning text in red :)

> and we explicitly strip setuid bits in both client->server
> and server->client directions. Not replacing the uid with some internal
> Coda uid which has no relation to anything happing on the clients when a
> file is created or written to seems to make sense to me. Because clients

Sure.

> don't have synchronized /etc/password files and pretty much everyone's
> local UID on their own machine is 1000 so almost every file is probably
> going to end up with uid 1000. This could lead to some end-user
> confusion.

Not only could but will and does.

> What to do with chown is probably a slightly harder decision. One option
> would be to always return permission denied on the client, but some
> applications may actually check the return code and fail badly. Another
> option is to report success, but not actually change the uid, which I
> think will break rpm and dpkg. The third option is to just let anyone

If I may speak on the matter, both rpm and dpkg are by definition/purpose
tools to maintain _local_ files on a host. Putting local objects on a
global file system like Coda would be odd per se as the semantics is
remarkably different.

With other words I wouldn't bother about packaging agents. They are
incompatible with Coda on more levels than chown() and a mix will hardly
work as expected anyway.

Such combinations (like rpm+Coda) are unfortunately a source of extra
confusion about best practices - when something seems to "work almost
properly" when it actually cannot be made to fully work.

> chown any file (that they have write permission for), because if they
> control their local machine and have write ACL rights they could have
> written to the file with whatever uid they please, effectively changing
> the uid to whatever they want if we aren't replacing them with the
> internal Coda userid anymore.

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
"local uid" which does not (and can not) fulfil any function in the
global context.

Most programs will be happy to believe that they own the data :)

Programs running as root and doing chown() on Coda and checking the result
do already break now, so we would hardly lose any functionality.

Regards,
Rune