Sascha Wilde <wilde@intevation.de> writes:
Timo Sirainen <tss@iki.fi> 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