Timo Sirainen tss@iki.fi writes:
On Oct 20, 2008, at 7:08 PM, Sascha Wilde wrote:
I understand the idea now, but see above: we need the (userdb only) checkpassword script to follow our rules anyway, so instead of doing magic to the environment and checking for this in checkpassword- reply it should be sufficient for the script to fail if AUTHORIZED wasn't set.
Or am I missing something?
The problem is that you said that AUTHORIZED is set automatically when userdb checkpassword script is called.
Yes, the userdb back end sets AUTHORIZED.
So the script doesn't have to set it manually.
Yes, the script doesn't change the environment in any other way than any qmail checkpassword script would.
That makes the script automatically work as userdb script (because AUTHORIZED is set automatically)
...yes, when it is called by the userdb backend...
and as passdb script (because AUTHORIZED isn't set automatically).
...when it is called by the passdb backend, yes.
That kind of breaks the idea.
Sorry I don't get it. The case we want to prevent is that a userdb only checkpassword gets accidentally abused by passdb for authorization, right?
Your solution is:
1. The userdb-only checkpassword script changes the environment in
some way.
2. checkpassword-reply detects the change and returns with an exit
code != 0
3. The passdb backend sees its child's exit code is != 0 and so the
authorization has failedMy solution:
1. The userdb-only checkpassword script sees no AUTHORIZED in the
environment and returns with an exit code != 0[0]
2. The passdb backend sees its child's exit code is != 0 and so the
authorization has failedSo whats the functional difference?
cheers sascha
[0] and != 2 as this is what the userdb backend expects for success as we decided.
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