(Illustration by Gaich Muramatsu)
On Fri, 27 Aug 2004, Ivan Popov wrote: > > Bigby Findrake <bigby_at_ephemeron.org> writes: > > > Has anyone stripped down coda to make it work without client > > > authentication? > > You do not need to strip down authentication, > just use it in the way which you find suitable. > > Setting ACLs allowing anonymous read and write will open your data > to the world, if it really is what you want :) > > "cfs sa /coda/your.realm System:AnyUser rlidwka" > > and the same at mountpoints before creating directories in new volumes. > > It may work fine, if you have a totally isolated network. > Otherwise you _do_ want authentication and protection. I'd like to start off by thanking you and all the others who have contributed so far. Your solution, from our perspective, does not allow us to take advantage of user and group permissions, which we would like to do. We would like remote accesses to the coda filesystem (eg. via ftp) to function with the permission of the user account making the access, so that things like ftp, nfs, smb/cifs, etc. could take advantage of the resiliancy of the coda filesystem n a manner that would be transparent to the end user. Any sort of group or global authentication would, at the very least, bypass user & group file permissions (read: protections). Additionally, all new files would be created by one user. We would like to retain user & group file protection modes. To reiterate, we don't want to operate without user and group identities, we just want processes to be able to access filesystem objects with the euid/egid of the process, not of the a(uthenticated)uid/a(uthenticated)gid. /-------------------------------------------------------------------------/ It seems strange to me that we all work so hard to live in comfort when all my best experiences in life have been under less than ideal circumstances. -Brian Rogers finger://bigby@ephemeron.org http://www.ephemeron.org/~bigby/ news://news.ephemeron.org/alt.lemurs /-------------------------------------------------------------------------/Received on 2004-08-29 03:51:20