[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