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.
--
Sylvain
_______________________________________________
Fusionforge-general mailing list
[email protected]
http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
