[Dovecot] Bug in driver-mysql.c + fix
addw at phcomp.co.uk
Wed Mar 10 19:03:49 EET 2010
On Wed, Mar 10, 2010 at 04:18:19PM +0200, Timo Sirainen wrote:
> On Fri, 2010-03-05 at 23:44 +0000, Alain Williams wrote:
> > This failed with the message:
> > User query failed: PROCEDURE imap.user_info can't return a result set in the given context
> I thought it was possible to avoid that error by implementing the MySQL
> procedure in a specific way?..
I have tried ... see another thread.
Just under the table near the top it says:
If your program uses CALL statements to execute stored procedures, the CLIENT_MULTI_RESULTS flag must be enabled.
> > The root of this problem is that mysql_real_connect() needs to be called with option CLIENT_MULTI_RESULTS
> The problem with doing that is that 1) it's not normally necessary and
> more importantly 2) doing that makes any potential SQL injection
> security holes a lot easier to exploit. So I'm not all that eager in
> adding such code, especially if it can be worked around another way..
CLIENT_MULTI_STATEMENTS allows multiple statements in one call (you separate by ',').
CLIENT_MULTI_RESULTS does not imply CLIENT_MULTI_STATEMENTS.
Is this what you were concerned about ?
Look at the URL above for details.
> > I am looking to use mysql procedures, there are some interesting things that can be done.
> > Two suggestions that I have will help with this:
> > 1) There be variable (say) %o - this be the obscured password, ie what password_query returns.
> > 2) that dovecot look for either ''password_query'' as above, or ''password_check''.
> > password_check would NOT return a password, but would be given %o and determine
> > itself if the password is correct.
> > It would return the other values (user, userdb_home, ...) and auth_result
> > that would encode success/retry/fail (0, 1, 2 - or maybe more structured [**])
> > and auth_reason some human readable reason.
> > The ''nologin'' value encodes some of this.
> > The motivation for this is that my stored procedure will record the number of successive
> > login failures and lock the account after 3 of them. It would also be possible to
> > do time based restrictions & the such.
> > Also: by passing %o the password is not sent in plain to the database server - which
> > will increase security.
> So what kind of obscuring where you thinking about? You could already
> use "%Mw", which gives you MD5 of the password.
That is not how I store passwords - I keep them as DIGEST-MD5, this is:
So I want %o to be that value. Squirrelmail should be able to deduce that from
the line in the dovecot-sql.conf:
> And password_query can already do basically what you were thinking about
> with password_check:
> password_query = select NULL as password, 'Y' as nopassword FROM users
> WHERE username = '%u' and password = '%w'
> or something. The main problem with that is that it can't differentiate
> between "wrong password" and "user doesn't exist", so it logs all
> password failures as "user doesn't exist".
I am trying to find a definition of the API to plugins, ...
if the SQL stored procedure can return arbitrary variables that can then be used
by PHP plugins then I can do things like issuing a warning about the password
about to expire, number of failed login attempts since the last success, ...
Ie all sorts of things that the authentication stored procedures could store
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
More information about the dovecot