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.
Require userdb scripts to set USERDB environment.
checkpassword-reply checks if USERDB environment is set. If it is, return exit code 2 instead of 0.
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.
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.
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.