On Mon, Nov 24, 2003 at 07:11:29PM -0800, Matthew Dillon wrote: > You don't need dynamic loading to get nsswitch type functionality. You > only need dynamic loading if nobody is willing to write an IPC > model to get the functionality. It's really silly to create such a > fundamental restriction on the binary because people are too lazy > to build an IPC based mechanism.
Matt, I'm not lazy. (Well, maybe I am, but that's not why I implemented NSS in the canoncial way instead of using IPC.) I've experimented with proxy-based solutions. Such solutions add a lot of complexity with little benefit. The primary NSS backends today are: NIS --- lightweight, proxy would just slow things down Hesiod --- lightweight winbindd --- lightweight (it implements its own proxy) nss_ldap --- could benefit IMHO, it makes more sense to write NSS modules that do their own proxying than to make things even more complicated in libc. Those that are lightweight don't carry extra baggage; those that do can implement proxying in the most efficient manner for that particular backend, e.g. some calls can be proxyed while others done in-process. You don't have to rewrite existing NSS modules so that they take into account that they are really serving multiple processes--- which usually means adding credentials management, locking, per-process state, and so forth to each NSS module. Or you could just create a whole new NSS API and call it something else and forget about support for existing NSS modules. Caching results (which is different than out-of-process implementations, the Linux nscd authors are just confused) does require a daemon, but this doesn't really complicate things. (I should get around to that someday :-) That said, I would not stand in the way of a well-thought out, well-written NSS implementation that attempts to proxy every get*() call over e.g. RPC. (Hmm, sounds like NIS to me. I guess that's partially explains why PADL.com's NIS<->LDAP gateway is popular :-) > Not only silly, but it seems to me > that it also creates security issues. At least with a client/server > model it is possible to isolate the authentication code to, for example, > disallow exec(), filesystem operations, or the opening of any new files. Um, if you can't trust the authentication code, what can you trust? Furthermore, for many many many applications that use getpwnam(3) and so on, increased privileges are not needed or wanted. And if you *are* really talking about authentication code (and not directory services), then you need to get PAM to work in a statically linked world, also. (You can compile PAM statically today, but that means no 3rd-party modules. The same holds for NSS, of course.) > The other huge advantage that IPC has over DLL is that you can switchout > the backend mechanisms on a running system without killing and restarting > anything other then he one service you want to switch out, and if it > doesn't work right you can restart the old one or keep live as a fallback. When using the current NSS implementation, there is no need to kill/restart anything when you update /etc/nsswitch.conf. New modules are dynamically loaded, and any no-longer-referenced ones are unloaded. > the IPC model is so much better then the DLL model for this sort of thing > I don't understand why people are even arguing about it. Because the rest of us are stupid and lazy, remember? :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"