Sascha Wilde <[EMAIL PROTECTED]> writes: > 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:
Please ignore this statement -- wrong test, wrong result ... The proposed change is not sufficient, the only reason why my test didn't fail was, that I used an other passdb backend, so that my userdb backend was the only one registering a SIGCHILD handler... 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
pgpdDygB0XVTs.pgp
Description: PGP signature
