[MDEV-11733] When access is denied due to SSL being missing, error message doesn't tell you Created: 2017-01-06  Updated: 2017-05-25

Status: Confirmed
Project: MariaDB Server
Component/s: Authentication and Privilege System
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Graham Leggett Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: upstream


 Description   

When an attempt is made to log into mysql with a user that requires SSL, and the client does not use SSL, the following error message is displayed:

170105 23:24:49    16 Connect   user@docs.example.com as anonymous on 
                   16 Connect   Access denied for user 'user'@'docs.example.com' (using password: YES)
 
                   17 Connect   user@docs.example.com as anonymous on

While the error message confirms that a password was present, the error message does not confirm whether SSL is present, and this causes significant confusion, particularly among people who are not DBAs.

The error message needs to be updated to include:

  • Whether a password was used (yes/no).
  • Whether SSL/TLS was used (yes/no).
  • Whether an SSL client certificate was used (yes/no).

 Comments   
Comment by Elena Stepanova [ 2017-01-11 ]

Same line is printed in the error log if log_warnings=2, no additional information there.
MySQL (including 5.7) also does not print anything about SSL. The reasoning in this old "won't fix" bug report is that such information shouldn't be provided to a user who fails to authenticate. I suppose if the message has to be the same in the logs and in the client, then the reasoning makes sense.

Comment by Graham Leggett [ 2017-01-11 ]

The error message I was referring to is in a log that is only visible to the administrator.

The bug report quoted https://bugs.mysql.com/bug.php?id=20899 is about displaying errors to the end user, which is something different.

Comment by Elena Stepanova [ 2017-01-11 ]

You are right, the correct reference would be this: https://bugs.mysql.com/bug.php?id=21565

Generated at Thu Feb 08 07:52:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.