MySQL Bugs: #51219: Verbose Login Failure Descriptions

Bug #51219	Verbose Login Failure Descriptions
Submitted:	16 Feb 2010 20:04	Modified:	6 May 2010 12:33
Reporter:	ivo welch	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Errors	Severity:	S4 (Feature request)
Version:	5.1.42	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	login query log

Description:

As a new user and administrator, I am often thoroughly baffled by how mysql decides whether to let me in or not.  This is not only mysql's fault---there are often further security overlays, such as apparmor, firewalls, and other security devices that can stop contact.  The forums have a good number of help requests from users who do not understand why they are having trouble.

To help track down unexplainable rejections , it would be terrific if there was a "login_log" that detailed exactly what an incoming user is seen as, and how/where he triggered acceptance and/or rejecting.

this could be a configuration option in my.cnf .

How to repeat:

everytime.

What about setting log_warnings=2? Check http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_log-warnings and http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html.

it's helpful, but it is not the same sort of information.  this is not about weirdly dropped connections, but about problems to begin with.  the information is also not detailed enough.  I need to know why I was refused.  I am user 'abc', but I am coming in from a domain that was not recognized, and thus is not authorized, for example.  I want to look up why 'abc' could not log in---guessing this is more difficult.

moreover, I would lay out the authentication log to another file.  the general query log fills up too fast with other requests.

regards,

/iaw

Hello Ivo,

I am able to follow you and understand your issue.

But it would be a great security lack when we would log login informations.

We can't risk this.

thank you susanne.  let me disagree for a moment.

[I am not suggesting that we log passwords with the attempts; I am suggesting that we log the reason why the failure occurs---"password was wrong".)

of course, it takes a security breach to access the log.  if there is a computer security breach, then we are already compromised.  presumably, in this case, I can even see the files that SQL stores, including the passwords.

and, it would seem to me that this would depend on the use.  it could be a temporary user setting in this case.  it could autorevert after one hour, for example.  or, while it is in login-debug mode, SQL could explain its actions in the log, but immediately log out the user after log-in.  this would allow experimenting that is not wholly in the dark.  it could also be user-specific---I need to figure out why certain users fail.  it would then log only when this user tries to log in.

some creativity could balance security concerns appropriately with the need to figure out why logins fail.

/iaw