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}