Hi Don,

Sorry, I do not have the necessary time resources to provide an introduction
into Coda security model and tools. It has not changed remarkably over time
so you may have a good use even of old documentation.

One cautionary note: there is a confusing feature concerning
the (ab)use of the s.k. "owner bits" to provide kind of per-file
access control. This control is enforced by the client side cache manager
and as such is worthless as a protection against anyone but oneself.
So if you want to understand the basic ideas, ignore all discussions
of the "owner bits" and do not touch those bits (let them to remain "on").
Then it is the directory ACLs who decide the access privileges.
Their semantics is properly enforced by the servers.

Another possible pitfall:
The OS kernel may cache access rights in addition to what
the Coda cache manager says, so if you change an ACL or reacquire tokens
some objects may look misteriously inaccessible or erroneously
accessible, due to the kernel taking wrong shortcuts behind the scenes.
It is not Coda's fault but it has to be dealt with.

On Tue, Jan 26, 2010 at 04:07:12AM -0800, root wrote:
> >For rudimentary permissions needs you need rudimentary setup,
> >for advanced needs you need an advanced setup. Coda offers reasonable
> >tools for both.
> 
> And those tools would be?  cfs sa? 

Also pdbtool for group management.

> >Forget chmod/chown.
> >Forget "client_host". It is irrelevant for access-rights-related
> >discussion.
> >Forget "logon". It has nothing to do with Coda security [model].
> >Forget "volume" when you are talking permissions, think "directory".
> 
> Forgotten. 

You are on the right way.

Good luck,
Rune