From owner-freebsd-current@FreeBSD.ORG Tue Nov 25 07:07:03 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD9B16A4CE for ; Tue, 25 Nov 2003 07:07:03 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E8F943FA3 for ; Tue, 25 Nov 2003 07:07:02 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 4C9B1548A3; Tue, 25 Nov 2003 09:07:01 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id E2E8D6D455; Tue, 25 Nov 2003 09:07:00 -0600 (CST) Date: Tue, 25 Nov 2003 09:07:00 -0600 From: "Jacques A. Vidrine" To: Matthew Dillon Message-ID: <20031125150700.GA48007@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Matthew Dillon , Peter Wemm , freebsd-current@freebsd.org, "M. Warner Losh" References: <20031125025621.453732A8FC@canning.wemm.org> <200311250311.hAP3BTCO075916@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311250311.hAP3BTCO075916@apollo.backplane.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: freebsd-current@freebsd.org cc: "M. Warner Losh" Subject: Re: 40% slowdown with dynamic /bin/sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2003 15:07:04 -0000 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 nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se