On Oct 20, 2008, at 8:57 PM, Sascha Wilde wrote:

Timo Sirainen <[EMAIL PROTECTED]> writes:

On Oct 20, 2008, at 8:00 PM, Sascha Wilde wrote:

My solution:

  1. 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:

1) userdb lookup: userdb-only checkpassword script setting AUTHORIZED=2 -> checkpassword returns 2 -> dovecot-auth assumes ok

2) passdb lookup: userdb-only checkpassword script setting AUTHORIZED=2 -> checkpassword returns 2 -> dovecot-auth fails the passdb lookup

3) userdb lookup: passdb-only checkpassword script doesn't set AUTHORIZED=2 -> checkpassword returns 0 -> dovecot-auth fails the userdb lookup

4) passdb 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.

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to