Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: >> On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: > [...] >>> So I guess what is needed is a new userdb backend which is explicitly >>> runs an arbitrary external program to get the user data (instead of >>> caching the passdb results). >> >> Right. Perhaps the passdb checkpassword code could be used as userdb >> too, just with an added extra variable specifying if it's a passdb or >> a userdb lookup. > > I just started to work on this feature
I have made a first rough sketch of the userdb-checkpassword back end,
basically by copying the code of the passdb version. Now I stumbled
upon the note "FIXME: if we ever do some other kind of forking, this
needs fixing" in sigchld_handler().
The only problem I experienced is, that the handler dosen't return, when
the signaling child wasn't listed in the modules clients -- but simply
replacing the continue with return like this:
--- a/src/auth/passdb-checkpassword.c Fri Oct 10 12:06:06 2008 +0200
+++ b/src/auth/passdb-checkpassword.c Fri Oct 10 21:34:36 2008 +0200
@@ -165,7 +165,7 @@
"with signal %d", dec2str(pid),
WTERMSIG(status));
}
- continue;
+ return;
}
if (WIFSIGNALED(status)) {
seems to fix this. The next handler is called and every thing seems to
work well (at least at a first very short test).
Is there any reason not to do so? And are there any other issues you
had in mind writing the FIXME?
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpjBtt4OXRgC.pgp
Description: PGP signature
