[Fusionforge-general] NSS loop
Sylvain
beuc at beuc.net
Sat Mar 22 17:47:25 CET 2014
On Wed, Feb 12, 2014 at 11:26:03AM +0100, Sylvain Beucler - Inria wrote:
> Le 11/02/2014 17:19, Roland Mas a écrit :
> >Sylvain Beucler - Inria, 2014-02-11 15:55:44 +0100 :
> >
> >>Hi Benoit,
> >>
> >> From the looks of it, nscd is hiding the problem rather than solving it.
> > Sort of, but not quite. From memory, the scenario without nscd is:
> >
> >- Something tries an NSS resolution (even something as trivial as
> > "getent passwd $user").
> >- The part of libc in charge of that reads nsswitch.conf, and sees that
> > it should call libnss-pgsql.
> >- libnss-pgsql is meant to connect to the database and do stuff with it,
> > so it calls stuff in libpq (the PostgreSQL client library).
> >- Before connecting, libpq tries to guess what to connect as, and this
> > includes checking what user it's running as…
> >- …which calls for an NSS resolution…
> >- …which goes to libnss-pgsql…
> >- …which detects a loop and blocks.
> >
> > With nscd, instead:
> >
> >- Something tries an NSS resolution (even something as trivial as
> > "getent passwd $user").
> >- The part of libc in charge of that asks if nscd knows the answer; it
> > doesn't, so libc reads nsswitch.conf, and sees that
> > it should call libnss-pgsql.
> >- libnss-pgsql is meant to connect to the database and do stuff with it,
> > so it calls stuff in libpq (the PostgreSQL client library).
> >- Before connecting, libpq tries to guess what to connect as, and this
> > includes checking what user it's running as…
> >- …which calls for an NSS resolution…
> >- …which goes to nscd…
> >- …which detects a loop and fails, so…
> >- …libpq goes on without guessing stuff…
> >- …connects to the database…
> >- …returns the results…
> >- …and libc returns the appropriate data, filling the cache in nscd on
> > the way.
> >
> > A more stable way of doing things would be to avoid the need for the
> >recursive lookup. Maybe using libnss-db or libnss-cache, with a job
> >that updates that database when needed.
> If we start doing crons for user authentication, we might as well
> ditch the whole NSS infrastructure and go back to good'ol
> /etc/passwd&group replication crons ;)
>
> Maybe it's just cleaner to setup a password-based access to the
> database when it's related to NSS.
Actually that won't do:
- a password-based access indeed works _without_ nscd locally, but
remote access will hang whatever the auth method(!)
- https://bugs.debian.org/551389 notes that the gforge_nss db user
could modify its own password, so any user on your system can break
NSS since he can read the base credentials in nss-pgsql.conf...
So even if we were local-only and/or the first dead-lock were fixed,
we'd also have to implement new password-changing restrictions in
postgresql to avoid the DoS.
So let's promote 'unscd|nscd' as a dependency, we can't do without it.
--
Sylvain
PS: bonus bug: 'getent shadow' now freezes unless you're root,
whatever the configuration :/
More information about the Fusionforge-general
mailing list