Hi Luke, On Sat, Jan 22, 2005 at 06:48:11PM +0000, Luke Kenneth Casson Leighton wrote: > if you run the entire file server out of, say, a database (e.g. like > Apache Subversion / WebDav) and also the security and the concept of > the user is managed independently of the POSIX / Unix idea of security, > who _gives_ a monkeys about UIDs - they're completely and utterly > irrelevant.
sure, I meant the client side. > which is why it's so much simpler, cleaner and just not so much of a > pig if everything client-side is done in userspace [KDE / Gnome > filesystem plugin...] Let's see. The least common denominator for all processes' i/o is the corresponding host's OS' system calls. It means we have to intercept them (via tracing?). Then we need to hand over a "real" file to the process, otherwise things like mmap() stop working. I think it can be pretty hard to do it in a general and efficient way totally in user space. May be just nobody has tried hard enough?.. > where UIDs become relevant is when you start messing about with trying > to present files from one Unix filesystem in a consistent manner on > another Unix workstation. > > so then, all parties - all file servers and all workstations, and all > processes accessing the same files - need to have the same view of the > world: a distributed UID database. Not really, though it depends on what we call a "consistent" manner. You can trick "ls" into displaying something feasible _without_ relying on a global uid space. LUFS does such tricks, for example. > DFS has all that - from what i can gather - via CDS - cell directory > services, and someone has made an effort to write a PAM plugin for DCE Christer Bernerus at Chalmers wrote the (appreciated) pam_dce module. > CDS, and an nsswitch module, etc. which "gives" you a consistent view > of your UID database across all workstations in the same "domain". But only inside one cell. Global access in DFS is still hardly possible (except for anonymous read). Regards, -- Ivan _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
