On Thu, Oct 11, 2001 at 12:35:38PM -0700, Randy Harmon wrote:
> What is the design for Coda in the area of Unix file permissions?  My
> assumption is that it's supposed to honor them, since it does in some

Coda basically doesn't honor unix permission bits, doesn't know anything
about the local groupid and doesn't care whether the local userid is or
is not identical to the Coda identity of the user. All access control is
based on the ACL of the parent directory.

However in a few situation we've had to add 'hacks' to allow
applications that expect certain UNIX filesystem-like behaviour to work.

> cases.  For instance,  I notice that I can't chown a file whose owner
> is somebody else.  Oh, I see in the archives that it's relying on some
> mix of Coda ACLs and Unix permissions.

Yeah, I was thinking of just allowing anyone to chown at any time. Coda
doesn't care and as only the server can really check whether the
operation is permitted this is currently a quick way of getting a
conflict in write-disconnected mode, i.e. the client allows and logs the
chown, but reintegration fails due to permission denied and the user can
scramble for his 'repair' tool.

> I would have expected that the Coda permissions controlled interaction
> between Venus and the coda server, and that the Unix permissions
> controlled interaction between the user and the mounted filesystem -

Depending on the operating system, the VFS does do some minimal checking
whether some accesses would be allowable or not.

> To be specific, I believe I found two bugs that should be easily
> correctable:
> 
> Since this file is mode -r-----, I can't open it for write, but I
> discover that I am allowed to chmod it.  This seems like a bug to me -
> not owner.  I have an ACL for this directory of 'rlidw'.

> Then there's a second bug, where only the 'owner' mode bits are
> tested - as if I am assumed to be the owner of the file.  The test is
> an 'echo random-junk > filename' command, with results as described in
> this table:

So, you have 'w' ACL permissions on the directory, enough to modify the
file and thus chmod it. Coda doesn't see 'group' or 'other', so yes,
only owner bits are tested and they are not compared against the owner
of the file, but used to restrict the permissions that are granted by
the directory ACL to the authenticated user.


> -r-------- root     root   filename   Permission denied (OK)
> -r-----rw- root     root   filename   Permission denied (BUG)
> -rw------- root     root   filename   file is written (BUG)

ACL (rlidw) . ownerbits (r) = rlid, no write permission.
ACL (rlidw) . ownerbits (r) = rlid, no write permission, not a bug.
ACL (rlidw) . ownerbits (rw) = rlidw, write permission, not a bug.

'x' unix permission bits are only a hint to the shell that the file can
be executed, I don't think any OS actually uses them for decisions.

Jan