Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] The code is now in dovecot-1.2 tree. Thank you, that's great! The only thing I'm missing is the addition to the example.conf I made. (I have to admit it was only a stub, though) http://hg.dovecot.org/dovecot-1.2/rev/4497c58eaca8 adds some other missing changes too. I also decided to change AUTHORIZED=YES to AUTHORIZED=1 initially. I did also think about yes - done or yes - userdb or something similar, but 1 - 2 seemed the best. Ack. There are more than 250LOC in deliver/auth-client.c and I wonder if there is already a higher level api for auth clients? I would have expected something like this in lib-auth, but the stuff in there seems not to be what I'm looking for. Any hints? plugins/expire-tool/auth-client.c has copypasted that code also.. So it would be nice if it was put to lib-auth :) Ok, I'll consider doing so... :) cheers sascha -- 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 pgpRjIAwWXtSd.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] [...] The code is now in dovecot-1.2 tree. Unfortunately there is one tiny, but essential change missing: diff -r afdc27e0b665 src/auth/auth.c --- a/src/auth/auth.c Wed Oct 22 21:11:47 2008 +0300 +++ b/src/auth/auth.c Thu Oct 23 13:11:25 2008 +0200 @@ -1,6 +1,7 @@ /* Copyright (c) 2005-2008 Dovecot authors, see the included COPYING file */ #include common.h +#include child-wait.h #include network.h #include buffer.h #include str.h @@ -32,6 +33,8 @@ auth-verbose_debug = getenv(VERBOSE_DEBUG) != NULL || auth-verbose_debug_passwords; auth-verbose = getenv(VERBOSE) != NULL || auth-verbose_debug; + + child_wait_init(); passdb_p = auth-passdbs; masterdb_p = auth-masterdbs; @@ -297,5 +300,6 @@ auth_request_handler_deinit(); passdb_cache_deinit(); + child_wait_deinit(); pool_unref(auth-pool); } cheers sascha -- 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 pgpK4sCPJFE6A.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Sascha Wilde [EMAIL PROTECTED] writes: Timo Sirainen [EMAIL PROTECTED] writes: On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote: There are more than 250LOC in deliver/auth-client.c and I wonder if there is already a higher level api for auth clients? I would have expected something like this in lib-auth, but the stuff in there seems not to be what I'm looking for. Any hints? plugins/expire-tool/auth-client.c has copypasted that code also.. So it would be nice if it was put to lib-auth :) Ok, I'll consider doing so... :) Having a first look it turns out to be less straight forward then I hoped it would be. While there are significant amounts of code similar in deliver/auth-client.c and expire/auth-client.c they differ in many aspects: 1.) It seems that some code in deliver/auth-client.c has been revised after it was copied to expire/auth-client.c, this is a small problem as I would expect simply using the newer code to be the right thing[tm]. 2.) The exported interface in the respective auth-client.h files is different. The solution would be to figure out what the right interface would be and change the current code to use it. My problem I'm not sure what the right interface would look like, for my use the one in expire/auth-client.h looks more compelling, what do you think? 3.) The deliver version does more than I need, and most certainly more than it should in the generic case: the most obvious example is that it sets up RESTRICT_* environment and calls restrict_access_by_env(TRUE); which surely is nothing I want to do in my code... My current plan is to take only the code from deliver/auth-client and check which parts I need, factor these out to new file in lib-auth (unfortunately lib-auth/auth-client already exists) and finally ask the author of the expire plugin to change his code so that it uses the new stuff in lib-auth (I doubt that I will have the time to do this on my own). Obviously a god answer on 2. is badly needed... ;-) One final question: All the code saves the gathered user data by setting the environment accordingly (especially HOME, which is the one of interest for my code) -- but in my case I'm requesting the data for foreign user so setting HOME wouldn't be good idea. I see two possible solutions: - Simple and stupid: save HOME, call the client-auth code, read HOME and reset its value to the saved one. - Clean but grows the API: export another function from auth-client, which does not set env-vars but returns the requested data in some struct. Any thoughts on that? cheers sascha -- 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 pgpwRtB98NPj0.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
On Thu, 2008-10-23 at 13:13 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] [...] The code is now in dovecot-1.2 tree. Unfortunately there is one tiny, but essential change missing: Oh. I guess I should have bothered to test it. :) I added the code to main.c now instead. I'll try merging changes differently the next time. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote:
1.) It seems that some code in deliver/auth-client.c has been revised
after it was copied to expire/auth-client.c, this is a small problem
as I would expect simply using the newer code to be the right
thing[tm].
Yes, I haven't really looked at expire/auth-client.c much lately.
2.) The exported interface in the respective auth-client.h files is
different. The solution would be to figure out what the right
interface would be and change the current code to use it. My
problem I'm not sure what the right interface would look like, for
my use the one in expire/auth-client.h looks more compelling, what
do you think?
Perhaps something like:
struct auth_user_reply {
uid_t uid;
gid_t gid;
const char *home, *chroot;
ARRAY_TYPE(const_string) extra_fields;
};
struct auth_connection *auth_connection_init(const char *auth_socket);
void auth_connection_deinit(struct auth_connection *conn);
/* Returns -1 = error, 0 = user not found, 1 = ok */
int auth_connection_lookup(struct auth_connection *conn, const char *user,
struct auth_user_reply *reply_r);
I'm not sure about the struct, but maybe something like that. deliver
would then use the struct to set up environment etc.
3.) The deliver version does more than I need, and most certainly more
than it should in the generic case: the most obvious example is that
it sets up RESTRICT_* environment and calls
restrict_access_by_env(TRUE); which surely is nothing I want to
do in my code...
Right. And in general putting all the stuff to environment directly
isn't that good. With v1.3's config rewrite I'm hoping to get rid of all
this environment usage.
finally ask the author of the expire plugin to change his code
That'd basically be me.
- Clean but grows the API: export another function from auth-client,
which does not set env-vars but returns the requested data in some
struct.
Yep.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: On Thu, 2008-10-23 at 13:13 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] [...] The code is now in dovecot-1.2 tree. Unfortunately there is one tiny, but essential change missing: Oh. I guess I should have bothered to test it. :) I added the code to main.c now instead. I'll try merging changes differently the next time. Thanks. v2.1alpha4? ;-) sascha -- 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 pgpT8zD7nf5gn.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote: [...] 2.) The exported interface in the respective auth-client.h files is different. The solution would be to figure out what the right interface would be [...] Perhaps something like: [api sketch] Looks good to me. Especially as it solves the put everything in the environment problem in a way I like... :-) I'm not sure about the struct, but maybe something like that. deliver would then use the struct to set up environment etc. 3.) The deliver version does more than I need, and most certainly more than it should in the generic case: the most obvious example is that it sets up RESTRICT_* environment and calls restrict_access_by_env(TRUE); which surely is nothing I want to do in my code... Right. And in general putting all the stuff to environment directly isn't that good. With v1.3's config rewrite I'm hoping to get rid of all this environment usage. Ok, so I'll touch it as few as possible and leave it in the deliver specific files. finally ask the author of the expire plugin to change his code That'd basically be me. :-) cheers sascha -- 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 pgpV4lUK2t9Qk.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
On Thu, 2008-10-23 at 18:55 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Thu, 2008-10-23 at 13:13 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] [...] The code is now in dovecot-1.2 tree. Unfortunately there is one tiny, but essential change missing: Oh. I guess I should have bothered to test it. :) I added the code to main.c now instead. I'll try merging changes differently the next time. Thanks. v2.1alpha4? ;-) Nah. checkpassword users are rare. :) signature.asc Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
Sascha Wilde [EMAIL PROTECTED] writes: Timo Sirainen [EMAIL PROTECTED] writes: On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote: [...] 2.) The exported interface in the respective auth-client.h files is different. The solution would be to figure out what the right interface would be [...] Perhaps something like: [api sketch] Looks good to me. One more detail: as lib-auth/auth-client.c already exists. Would it be a good idea to put the new stuff in the same file? And in case not, any suggestions what a new file could be named? cheers sascha -- 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 pgp8LyoUd3L7T.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
On Oct 23, 2008, at 9:15 PM, Sascha Wilde wrote: as lib-auth/auth-client.c already exists. Would it be a good idea to put the new stuff in the same file? And in case not, any suggestions what a new file could be named? Hmm. auth-client.c is about performing authentication as a client. What you're doing is about doing a userdb lookup and connecting to dovecot-auth as a master. So different file, but I'm not really sure about the name. Perhaps auth-master.c and auth_master_init/deinit() auth_master_user_lookup() function? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote: Timo Sirainen [EMAIL PROTECTED] writes: On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: [userdb-checkpassword] The code is now in dovecot-1.2 tree. Thank you, that's great! The only thing I'm missing is the addition to the example.conf I made. (I have to admit it was only a stub, though) http://hg.dovecot.org/dovecot-1.2/rev/4497c58eaca8 adds some other missing changes too. I also decided to change AUTHORIZED=YES to AUTHORIZED=1 initially. I did also think about yes - done or yes - userdb or something similar, but 1 - 2 seemed the best. There are more than 250LOC in deliver/auth-client.c and I wonder if there is already a higher level api for auth clients? I would have expected something like this in lib-auth, but the stuff in there seems not to be what I'm looking for. Any hints? plugins/expire-tool/auth-client.c has copypasted that code also.. So it would be nice if it was put to lib-auth :) signature.asc Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: Sascha Wilde [EMAIL PROTECTED] writes: Timo Sirainen [EMAIL PROTECTED] writes: [...] 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. Ok, you convinced me that your concept has the advantage of forcing the checkpassword script author to try to implement all aspects of the spec. I'll implement it this way, as it isn't hard to do anyway. Ok. 8ebf5a64e6eb includes the discussed changes. The code is now in dovecot-1.2 tree. I did some minor changes, mostly related to getting coding style consistent with the rest of Dovecot. It probably would have been possible to have the passdb and userdb share more code, but it's good enough now. :) PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: On Fri, 2008-10-17 at 19:04 +0200, Sascha Wilde wrote: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ Timo, what would be needed to get the new back end upstream? Some small things: - rename checkpassword-common.c to db-checkpassword.c so it's consistent with others. [x] done - userdb checkpassword is a new dovecot-specific extension, so you can drop all vpopmail etc. exit code handlers. Just 3 needed: success, user doesn't exist and internal error (also being the default). [x] done 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. - 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. 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. cheers sascha [0] I guess that's what you mean by userdb scripts -- 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 pgpOYKSU8z0El.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
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
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] writes: 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. Ah, I see. I'll implement it accordingly. - 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. Ok, we can agree on that. But I think it would be sufficient to say that such an userdb only checkpassword script MUST fail if AUTHORIZED is not set. 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. 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? cheers sascha -- 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 pgpYhzqfcC05l.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
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. So the script doesn't have to set it manually. That makes the script automatically work as userdb script (because AUTHORIZED is set automatically) and as passdb script (because AUTHORIZED isn't set automatically). That kind of breaks the idea. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen [EMAIL PROTECTED] 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 failed My 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 failed So 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 pgpIAkN16eNOx.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
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. 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. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
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. 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? cheers sascha -- 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 pgpXie3HUZoki.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
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. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] New userdb backend for checkpassword like programs
On Oct 20, 2008, at 10:40 PM, Timo Sirainen wrote: Ever since I took these Human-Computer-Interfacing classes I've started thinking about ways to make things more easier (and foolproof). There was this one example about how difficult it was to design a web page (about 10 years ago) that told the user to maximize the browser window and then click continue button to start the web application. Most people succeeded initially but getting the rest of the people to succeed was a lot more difficult. Unfortunately I don't have the URL for that page now. Anyway I think those people who failed at first could be thought of as fools, but with some more design it was possible to make it foolproof :) Found it :) http://www.asktog.com/columns/000maxscrns.html PGP.sig Description: This is a digitally signed message part
[Dovecot] New userdb backend for checkpassword like programs
As announced in MID [EMAIL PROTECTED] I wrote[0] a new userdb back end, which uses a checkpassword like program to retrieve user data. This is needed to get computed user data without authentication for the LDA or the yet to be implemented %%h variable in shared user folder name spaces... The back end needs a special checkpassword program which follows the qmail semantics but additionally provides the user data without password verification when the environment variable AUTHORIZED is set.[1] I have done some code cleanup (mainly factoring out common code of the passdb and userdb back ends) and you can found the current version, alongside with our acl-plugin enhancements, here: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ Timo, what would be needed to get the new back end upstream? cheers sascha [0] Well mostly copy and paste from the existing passdb-checkpassword... [1] The variable name needs some evaluation: it seems, that courier knows an environment variable AUTHENTICATED, which might be a good choice for us, too -- on the other hand it might be totally wrong. ;-) -- 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 pgpfrdEnqeJJV.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
On Fri, 2008-10-17 at 19:04 +0200, Sascha Wilde wrote: The back end needs a special checkpassword program which follows the qmail semantics but additionally provides the user data without password verification when the environment variable AUTHORIZED is set.[1] I have done some code cleanup (mainly factoring out common code of the passdb and userdb back ends) and you can found the current version, alongside with our acl-plugin enhancements, here: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ Timo, what would be needed to get the new back end upstream? Some small things: - rename checkpassword-common.c to db-checkpassword.c so it's consistent with others. - userdb checkpassword is a new dovecot-specific extension, so you can drop all vpopmail etc. exit code handlers. Just 3 needed: success, user doesn't exist and internal error (also being the default). - a valid userdb checkpassword script shouldn't be a valid passdb checkpassword script to avoid accidents. I guess this could be done by 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. signature.asc Description: This is a digitally signed message part
