[MXS-4605] Monitor should drop the connection when faced with an Access Denied error Created: 2023-05-01 Updated: 2023-05-16 |
|
| Status: | Open |
| Project: | MariaDB MaxScale |
| Component/s: | Monitor |
| Affects Version/s: | 22.08.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Martin Reinhardt | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | grants, maxscale, user | ||
| Description |
|
If monitors don't have the require grants and an operation causes an error to occur, the monitor does not drop the connection to the server. New global grants (e.g. READ_ONLY ADMIN) are only applied to connections created after the grants were given. Original description: For example, in the error message below, the customer granted the missing READ_ONLY ADMIN privilege, but it only became effective after restarting the MaxScale service: error message displayed was: "[mariadbmon] Setting read_only on 'node-0' failed: 'Access denied; you need (at least one of) the READ_ONLY ADMIN privilege(s) for this operation." |
| Comments |
| Comment by Johan Wikman [ 2023-05-02 ] |
|
That warning was from the monitor. The situation could probably have been resolved by stopping and starting the monitor. |
| Comment by markus makela [ 2023-05-02 ] |
|
The reason why it worked is because the connection was recreated due to the restart of MaxScale. You could've achieved the same effect with one of:
|
| Comment by markus makela [ 2023-05-02 ] |
|
I think this could be converted into a bug since it's supposed to work "seamlessly" without requiring any user action. I'd imagine that upon noticing a grant error the monitor could recreate the connection in the hopes that the grant problem has been fixed. |
| Comment by Dylan Northrup [ 2023-05-02 ] |
|
As the customer who requested this ticket be created, I wanted to clarify my understanding of the suggested remedy. Based on a naive reading of the updated title and summary, it seems like the direction is to have the monitor close the connection and reconnect if it encounters an error with the GRANTs of the user associated with the monitor. This seems like it would be a disruptive action, especially if the error arises from a configuration update that causes Maxscale to attempt an activity it had not previously tried (eg. modifying enforce_read_only_slaves from false to true). Having the behavior of your proxy depend on when it was last started makes that behavior less predictable the longer the system is running. The preferable option would be for the monitor to detect if/when there's a change in GRANTs and either use additional GRANTs or warn that functionality is unavailable. Right now it appears the monitor locks in it's belief in its abilities when it starts up and will try to execute commands regardless of whether or not its permissions have been modified. NOTE: This is true even if a specific GRANT has been removed (say READ_ONLY ADMIN in the enforce_read_only_slaves example) but another GRANT (say SUPER will allow the monitor user to perform the requested action). I will be uploading logs showing this behavior in the originating support case. |
| Comment by Johan Wikman [ 2023-05-03 ] |
|
The primary point is that the monitor should be smarter than what it currently is. The suggested remedy was likely just an initial idea that may or may not be what eventually is implemented. As such, reconnecting is business as usual, as connections tend to break at times due to various network issues. Currently the monitor does not check what grants the user it has been configured with has, but assumes the user has the required grants for the operations that will be attempted. |