Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
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.
Attachments
Issue Links
- is blocked by
-
-
- Closed
-
- relates to
-
MDEV-17169 password ignored with root login
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue relates to |
Hi danblack,
Was the password changed with direct manipulation of the mysql.user table rather than one of the password set mechanisms?
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.
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.
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.
| Fix Version/s | 10.3 [ 22126 ] |
| Assignee | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] |
| Link |
This issue is blocked by |
| Link |
This issue relates to |
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) MDEV-12321
| Labels | authentication logging unix_socket | authentication unix_socket |
| Epic Link | PT-73 [ 68549 ] |
| Rank | Ranked higher |
| Assignee | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] | Sergei Golubchik [ serg ] |
| Link |
This issue relates to |
| Fix Version/s | 10.4.0 [ 23115 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
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?
| Workflow | MariaDB v3 [ 80827 ] | MariaDB v4 [ 133259 ] |
| Zendesk Related Tickets | 172650 |
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.