On Sat, Jan 22, 2005 at 05:56:53PM +0100, Ivan Popov wrote: > Thanks Tom, > > now I understand your point better. > > On Fri, Jan 21, 2005 at 04:56:16PM -0500, Tom Keiser wrote: > > cache manager: > > - responsible for storage of data and metadata > > - responsible for cache replacement strategy > > - API for interaction with implementation of VFS interface > > - API for access by RPC endpoint for things like cache invalidation > > On Coda list we have had a small discussion about splitting out cache space > reclaimation from the (user space) cache manager. > It seems feasible, and possible in a portable way. > I doubt though that a similar approach would work for AFS or DFS as their > cache is a lot more complicated. > > > credential manager: > > - example would be the linux 2.6 keyring implementation > > <skippable> > I think all that keyring business is a try to "work around" a basic > Unix principle - that credentials are tied to an UID, that's it.
that's only relevant _if_ you are accessing files - and if you are accessing them via the POSIX subsystem. 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. 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...] 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. 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 CDS, and an nsswitch module, etc. which "gives" you a consistent view of your UID database across all workstations in the same "domain". An attempt was made to do the same thing with Samba, with a program called "winbindd", but unfortunately, the people who were in control of writing it did not take into account the need to "distribute" the UIDs consistently across multiple unix workstations. consequently, with winbindd, you can join Unix workstations to an NT Domain, you can run pam_winbindd and nsswitch_winbindd, so you have the same "names" but the uids could differ, depending on who logs in first! actually it wouldn't be difficult to distribute the sid<->uid/gid entries, all you'd need to do was have one central server which controls lookups for all workstations. > It can work as a conveniency feature, but it just hides the fact - > if you need separate security domains for different processes, they > have to be of different UIDs, otherwise the system cannot protect them > from each other (except possibly for special cases like jailed/chrooted). and selinux, which "tracks" processes in a predefined way [making sure that they only make certain system calls] but that's a different story. > The rights management in a Unix-like system is tied to UIDs, not to PAGs > or alike. We'd have to redesign all syscalls to be able to securely use PAGs. > </skippable> ... or you have a central lookup table service which your nss_myweirdservice is told about, looks stuff up in. ... it's not difficult - just necessary to get your head round a few weird ideas involving lots of machines rather than just one. anyway - i _really_ wish Unix had VMS/NT Security Descriptors not this stupid single 32-bit rubbish, it _really_ would make life a lot easier. > > implementation of VFS interface: > > - very os-specific stuff > > - probably in-kernel unless something like LUFS takes off > > LUFS seems to mean "Linux Userland File System" which does not promise a lot > about portability? solution for linux is a solution for linux: i presume that there exist userspace filesystem drivers for other OSes? and even a solution for linux requires that the uids be consistent and possible to look up (see above) but contacting a remote service to find out your uid is an _awful_ lot easier to do in userspace than it is in kernel-land. the thought of doing that kind of thing in-kernel just makes me wanna puke - it's just _so_ inappropriate! l. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
