On Tue, Jan 31, 2006 at 04:00:07PM -0500, Greg Troxel wrote:
> That makes sense, but I wonder about richer mapping, *very* roughly:
...
>   if the calling user's coda uid is in the acl, enable group bits
> 
>   if System:AnyUser, enable other bits

I tried something along these lines, I ignored the userid mapping and
displayed every file as,

    uid -> local userid of caller
    gid -> some fixed group (coda_authusers)

And then mapped the modebits as follows,

    caller ACL rights 				     -> user bits
    logical OR of ACL rights for authenticated users -> group bits
    System:AnyUser rights			     -> other bits

This was done as a one-way mapping, so chown/chmod simply returned
success, changed the bits internal to Coda but didn't really change
anything in the representation.

The problems that were most obvious weren't that application broke, but
some problems with the kernel inode caching. The kernel couldn't be
allowed to cache inode information, which pretty much kills performance.
The directory cache entries can't exist without valid inodes, so even
lookups ended up always going back to venus. There was also a race when
several local users are doing a near-simultaneous lookup, because the
lookups are uncached they take long enough to get the second one waiting
for the first one to complete and it then skips the revalidation/upcall
(normal filesystems don't have different stat/lookup results based
on the calling user) and returns the wrong information for the second
user.

But I still find this idea interesting, there have been changes in the
VFS that might solve this, I believe that a getattr method was
introduced for inodes that might help.

Of course this still could cause problems for rpm/dpkg type installers,
or tar -x, which check if the chown/chmod actually worked correctly.

Jan