Greetings all: 


>> > See the wiki for limitations.
> 
>  http://coda.wikidev.net/Limitations

Perfect! 


>> a *nix filesystem, I would simply chmod the directory 711 with directory 
>> contents 644/755 (file/dir) -- contents of directory are globally 
>> accessible, so long as one knows the name. 
> 
> I see, you do not want the names to be visible.
> There is an ACL 'l' flag for directory readability. 
> 
> -------------------------------------------------------------------- 
> 
> A bit of gory details on ACLs in general: limiting access to some
> directory does not necessarily limit access to all paths under that
> directory as somebody else can mount volumes in an arbitrary tree and
> thus bypass some parts of paths. In that sence volume root directories
> are special. 
> 
> On the other side, you should not assume that protecting a volume root
> directory protects all data in that volume. There may be ways to access
> other objects in the volume given some extra information and given a
> suitable ACL on _that_ object['s directory]. So better do not assume
> transitivity of the ACLs even inside a single volume. If curious see a
> recent discussion on openafs-devel list.

I'm confused.  By this, it almost appears that there is no file access 
security within coda.  I.E.:  If a user can login to a given coda.realm, a 
sufficiently motivated individual with said user access could gain 
unauthorized access to any file available within that realm. 

However, I think what must have been meant is that as long as ACLs are set 
on all directories to provide access only to a given user, those files 
should be secure from a different user on a different client host.  That 
seems like a godawful amount of setup and maintanence for rudimentary file 
access permissions, however.  I still don't think I've got it right. 

Given the following environment, what is the minimum ACL/chmod/chown 
necessary to provide sandboxed access: 

coda_user_1 only can logon to client_host_1 which has exclusive listing, 
read, and write access to coda_volume_1 

coda_user_2 only can logon to client_host_2 which has exclusive listing, 
read, and write access to coda_volume_2 

coda_user_1 can NOT logon to client_host_2
coda_user_1 can NOT see coda_volume_2 

coda_user_2 can NOT logon to client_host_1
coda_user_2 can NOT see coda_volume_1 


Obviously, if we need to have a coda_volume_1/coda_dir_1 (etc.) to provide 
this functionality, that is fine. 


Regards,
 -Don
{void}