Dear Dovecot-Team, I am implementing a plugin (for the pop3/imap process) that requires some data to provided from the authentication phase (a derivative of the password). For that, I have now implemented a passdb plugin that generates this data and I would like to "pass" this data down to the mail process (pop3/imap) via extra_fields in the reply of the authentication. The general idea is that my custom passdb plugin calculates the data, sets the extra_field and returns some error (authentication was not successful) so that the "real" passdb backend can be invoked to "really" validate the authentication data. However, in auth_request_handle_passdb_callback() the extra_fields are reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if that return code is used then any following passdb's aren't invoked any more - which makes sense with respect to user authenticiation. I would therefore like to propose that some IGNORE/CONTINUE-status to be introduced in auth/passdb.h, that would be handled in that extra_fields and possible other values are not reseted in order to allow such propagation of data from authentication process down to the mail process (which could be extracted from the reply string by parsing it). As a further implementation alternative (to the parsing of the reply string), I also propose that some new "environment" item be introduced (in auth_request) in order to allow such data passing in a generic manner. I hope you consider my proposal to be reasonable. If desired, I could implement this myself and provide a patch for merging (based on 2.0.x). If my proposal is generally unfavored, it would be great if any alternative approaches for my situation were suggested. Thanks. Regards, J?rgen PS: please reply to my e-mail (or CC me), as I have not subscribed to the dovecot list
On 2012-06-24 4:37 PM, J?rgen Pabel <juergen at pabel.net> wrote:> I am implementing a plugin (for the pop3/imap process) that requires > some data to provided from the authentication phase (a derivative of the > password). For that, I have now implemented a passdb plugin that > generates this data and I would like to "pass" this data down to the > mail process (pop3/imap) via extra_fields in the reply of the > authentication. The general idea is that my custom passdb plugin > calculates the data, sets the extra_field and returns some error > (authentication was not successful) so that the "real" passdb backend > can be invoked to "really" validate the authentication data.What specifically is the *purpose* of this?> I hope you consider my proposal to be reasonable. If desired, I could > implement this myself and provide a patch for merging (based on 2.0.x). > If my proposal is generally unfavored, it would be great if any > alternative approaches for my situation were suggested. Thanks.I think it is usually preferred that you do things like this against either the current shipping/stable branch (2.1.x), or even hg (2.2)... much better chance that it would be accepted. -- Best regards, Charles
Hi, I am replying to my own message because it's probably the "cleanest" reply since I am not subscribed to the mailing list and thus can't reply to Charles' message itself.> What specifically is the *purpose* of this?To encrypt the data on the server (like the zlib plugin does for compression). Said value will be password used to unlock/decrypt the encryption key stored on the server. (I have implemented several cryptographic software components, so I believe that I understand what all is required for something like such a plugin to be implemented correctly).> I think it is usually preferred that you do things like this against > either the current shipping/stable branch (2.1.x), or even hg (2.2).. > much better chance that it would be accepted.Agreed - I'm just developing on Ubuntu 12.04 which has 2.0. However, porting patches from 2.0 to 2.1/2.2 shouldn't be too hard from what I've seen so far. Cheers, J?rgen Am Sonntag, den 24.06.2012, 22:37 +0200 schrieb J?rgen Pabel:> Dear Dovecot-Team, > > I am implementing a plugin (for the pop3/imap process) that requires > some data to provided from the authentication phase (a derivative of the > password). For that, I have now implemented a passdb plugin that > generates this data and I would like to "pass" this data down to the > mail process (pop3/imap) via extra_fields in the reply of the > authentication. The general idea is that my custom passdb plugin > calculates the data, sets the extra_field and returns some error > (authentication was not successful) so that the "real" passdb backend > can be invoked to "really" validate the authentication data. > > However, in auth_request_handle_passdb_callback() the extra_fields are > reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if > that return code is used then any following passdb's aren't invoked any > more - which makes sense with respect to user authenticiation. I would > therefore like to propose that some IGNORE/CONTINUE-status to be > introduced in auth/passdb.h, that would be handled in that extra_fields > and possible other values are not reseted in order to allow such > propagation of data from authentication process down to the mail process > (which could be extracted from the reply string by parsing it). > > As a further implementation alternative (to the parsing of the reply > string), I also propose that some new "environment" item be introduced > (in auth_request) in order to allow such data passing in a generic > manner. > > I hope you consider my proposal to be reasonable. If desired, I could > implement this myself and provide a patch for merging (based on 2.0.x). > If my proposal is generally unfavored, it would be great if any > alternative approaches for my situation were suggested. Thanks. > > Regards, > J?rgen > > PS: please reply to my e-mail (or CC me), as I have not subscribed to > the dovecot list >
On 24.6.2012, at 23.37, J?rgen Pabel wrote:> I am implementing a plugin (for the pop3/imap process) that requires > some data to provided from the authentication phase (a derivative of the > password). For that, I have now implemented a passdb plugin that > generates this data and I would like to "pass" this data down to the > mail process (pop3/imap) via extra_fields in the reply of the > authentication. The general idea is that my custom passdb plugin > calculates the data, sets the extra_field and returns some error > (authentication was not successful) so that the "real" passdb backend > can be invoked to "really" validate the authentication data.This is a bit related to another feature people have requested: Ability to merge data from multiple userdbs into a single reply. Perhaps the same could be done for passdbs. Also in my TODO is that master=yes passdb currently preserves userdb extra fields, but not passdb extra fields and that behavior probably isn't optimal. There is already passdb { pass=yes } setting for masterdbs. I guess the same could be used for non-masterdbs and also added to userdbs.> However, in auth_request_handle_passdb_callback() the extra_fields are > reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if > that return code is used then any following passdb's aren't invoked any > more - which makes sense with respect to user authenticiation. I would > therefore like to propose that some IGNORE/CONTINUE-status to be > introduced in auth/passdb.h, that would be handled in that extra_fields > and possible other values are not reseted in order to allow such > propagation of data from authentication process down to the mail process > (which could be extracted from the reply string by parsing it).Yes, extra_fields really need to get reset between passdb calls. Same for userdb_reply.> As a further implementation alternative (to the parsing of the reply > string), I also propose that some new "environment" item be introduced > (in auth_request) in order to allow such data passing in a generic > manner.Maybe a new permanent_extra_fields, which gets added as default to new passdb/userdb lookups. If the lookup has pass=yes, the result gets added to permanent_extra_fields. Although the code is beginning to have too many extra_fields variables. Maybe it would be possible to merge extra_fields, extra_cache_fields and userdb_reply into one array of structs: struct auth_field { const char *key, *value; bool cache_only; bool userdb; bool permanent; };> I hope you consider my proposal to be reasonable. If desired, I could > implement this myself and provide a patch for merging (based on 2.0.x). > If my proposal is generally unfavored, it would be great if any > alternative approaches for my situation were suggested. Thanks.I could add such a patch to v2.2.