On Wed, May 05, 2010 at 07:37:35PM +0200, u+codalist-wk5r_at_chalmers.se wrote:
> > 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 :)

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.

> 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.

Jan