NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

Matthew Dillon <dillon_at_apollo.backplane.com> writes:

>     How much do you intend to use NSS for?  I mean, what's the point of
>     adopting this cool infrastructure if all you are going to do with it
>     is make a better PAM out of it?

The important thing is that NSS allows to plug modules such as LDAP or
PostgreSQL for user base management. PAM is only halfway there and
doesn't give libc et al. a notion of a user or group context (in spite
of its "account" context), NSS does. One might discuss if PAM is really
needed with NSS in place, but it's hard to think of a system without
NSS and removing PAM now doesn't look right.

Of course, you can stuff the whole NSS client side (thinking "IPC")
into a statically linked executable. To stall this discussion: I don't
mind if NSS is dynamically or statically linked. I won't let this drift
into any other dynamic <-> static discussion.

>     reason that I can see, and coming up with all sorts of extra junk,
>     like /rescue, to work around that fact.

As a user, I like /rescue better than the step-child that /stand/* used
to be. It's part of the world, which /stand wasn't.

One word of warning: there used to be SuSE Linux versions that wouldn't
let you log in single-user mode when the system was using NIS in
multi-user because there was nothing to communicate with through AF_UNIX
sockets yet this was expected to be able to log in. There are potholes
and pitfalls that I consider major considered with a dynamic /bin /sbin
setup.

Watch out.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95