On Oct 20, 2008, at 8:57 PM, Sascha Wilde wrote:
Timo Sirainen <tss@iki.fi> writes:
On Oct 20, 2008, at 8:00 PM, Sascha Wilde wrote:
My solution:
- The userdb-only checkpassword script sees no AUTHORIZED in the environment and returns with an exit code != 0[0]
You assume that the script actually checks this.
More than that, I defined that it MUST do so. As you said, it's a new variant, so _we_ can define how it has to
behave.
People are badly behaving :) There's nothing that's technically
forcing to check that.
There's no requirement that a userdb-only script needs to bother
doing it. The use of AUTHORIZED environment is necessary only if the script wants to handle both passdb and userdb.But you are requiring the userdb-only checkpassword program to set AUTHORIZED (or any other environment variable) to a specific value.
Why should a developer ignoring my requirement bother to obey yours?
If you aren't changing AUTHORIZED environment to a specific value, the
userdb lookup will fail because checkpassword-reply sees that it's not
set correctly. So the handling goes like:
userdb lookup: userdb-only checkpassword script setting
AUTHORIZED=2 -> checkpassword returns 2 -> dovecot-auth assumes okpassdb lookup: userdb-only checkpassword script setting
AUTHORIZED=2 -> checkpassword returns 2 -> dovecot-auth fails the
passdb lookupuserdb lookup: passdb-only checkpassword script doesn't set
AUTHORIZED=2 -> checkpassword returns 0 -> dovecot-auth fails the
userdb lookuppassdb lookup: passdb-only checkpassword script doesn't set
AUTHORIZED=2 -> checkpassword returns 0 -> dovecot-auth assumes ok
All of this forces that the checkpassword script developer either
handles the AUTHORIZED environment correctly or it doesn't work at
all. And it prevents admin from accidentally using the script wrong.