On Mon, 2008-10-20 at 17:26 +0200, Sascha Wilde wrote: > Currently the code handles only two cases: success and (any kind of) > error. The passdb-checkpassword stuff seems not to handle "user > doesn't exist" in any special way, so I don't see why the userdb > backend should.
The difference is that userdb lookups need to know if the user exists or if the error is only temporary. That determines if deliver returns EX_TEMPFAIL or EX_NOUSER. > > - a valid userdb checkpassword script shouldn't be a valid passdb > > checkpassword script to avoid accidents. I guess this could be done by > > I don't agree here. I think it would be ok to have only one > checkpassword executable to handle both cases. Yes, but a checkpassword script written to handle *only* userdb lookups shouldn't be a valid passdb script. > > 1) Require userdb scripts to set USERDB environment. > > > > 2) checkpassword-reply checks if USERDB environment is set. If it is, > > return exit code 2 instead of 0. > > > > 3) userdb-checkpassword.c's success exit code is 2. exit code 0 would > > produce failure. > > > > Hmm. Or perhaps instead of USERDB change the AUTHORIZED environment's > > value to something else. > > 1) I fully agree that it is a very good idea that, if AUTHORIZED is set > checkpassword-reply should return something != 0 at success and > userdb-checkpassword should expect this very value. > > I'll implement that. > > 2) I don't understand why the checkpassword program[0] should change the > environment in any way. The idea was that if there's a checkpassword script that handles only userdb lookups and it's tried to be used as passdb checkpassword, it would fail because checkpassword-reply sees AUTHORIZED=2 environment, which would cause it to return 2 which would cause passdb checkpassword to fail the authentication. The rest of it is to just get this idea working for both passdb and userdb lookups.
signature.asc
Description: This is a digitally signed message part
