[MDEV-12835] Write warning to error log if user's login password is ignored Created: 2017-05-17 Updated: 2020-08-25 Resolved: 2018-11-07 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Authentication and Privilege System |
| Fix Version/s: | 10.4.0 |
| Type: | Task | Priority: | Major |
| Reporter: | Geoff Montee (Inactive) | Assignee: | Sergei Golubchik |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | authentication, unix_socket | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
A user recently found out that the password for his 'root'@'localhost' account was being ignored. It turns out that his build of MariaDB uses unix_socket authentication by default for that user account. However, he was not aware of that, so he still attempted to set a password for this user account. He was also not familiar with the unix_socket plugin, so he was quite confused when he discovered that he could log into MariaDB without supplying a password after he explicitly set one. The user suggested that it might be worthwhile for the server to throw a warning when a user's provided login password is ignored. For security reasons, it might make sense to only write the warning to the server's error log. Maybe this warning could be toggled on/off based on the value of log_warnings, similar to the other warnings thrown by authentication issues. I'm not entirely familiar with internals of the authentication plugin API, so I don't know how practical this feature request is with the current implementation. |
| Comments |
| Comment by Daniel Black [ 2017-05-17 ] |
|
Was the password changed with direct manipulation of the mysql.user table rather than one of the password set mechanisms? Seems to be a misunderstanding issue that Unix with was there compounded by a belief that passwords are more secure and potentially an unsupported (but commonly bloged) change mechanism. |
| Comment by Geoff Montee (Inactive) [ 2017-05-17 ] |
|
Hi danblack,
Nope. The password was initially set with mysql_secure_installation (which apparently didn't pay attention to or change the existing "plugin" value for root@localhost), and then it was set again with SET PASSWORD, which also seemed to ignore "plugin". MariaDB apparently allowed the password to be set in both of those cases, even though the password is meaningless when the account has plugin=unix_socket.
I don't entirely follow what you mean (there seems to be some typoes in your comment), but the user definitely misunderstood what was happening in this case. They weren't familiar with the unix_socket plugin at all. This issue isn't really taking a stance on whether unix_socket is better than password authentication. The user just thought that MariaDB should notify the DBA when a user thinks they are logging in with a password, when in reality, the password is being ignored. The main reason is that it might indicate that the DBA or user doesn't really understand how their server's authentication works, so there might be more serious problems with how the accounts are setup. |
| Comment by Sergei Golubchik [ 2018-04-23 ] |
|
At the very least we can refuse SET PASSWORD and IDENTIFIED BY for accounts with authentication plugins that do not need passwords at all. This could be done in (or after) |
| Comment by Sergei Golubchik [ 2018-11-07 ] |
|
Handled in |
| Comment by Geoff Montee (Inactive) [ 2019-06-14 ] |
|
To clarify this change, MariaDB 10.4.0 and later contains a new warning for when a user attempts to change a password with SET PASSWORD or IDENTIFIED BY and the user account's authentication plugin does not require a password, but it does not contain a new warning for when a user provides a password to log in and a password is not required. Is that correct? |