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}

Reply via email to