Re: 40% slowdown with dynamic /bin/sh

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_at_celabo.org jvidrine_at_verio.net nectar_at_freebsd.org nectar_at_kth.se