[MXS-4414] MaxScale logs passwords in SQL at the info level Created: 2022-11-25 Updated: 2022-12-13 Resolved: 2022-12-08 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | N/A |
| Affects Version/s: | None |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Anurag Kumar (Inactive) | Assignee: | Johan Wikman |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Environment: |
MaxScale 22.08.2 |
||
| Attachments: |
|
| Sprint: | MXS-SPRINT-172 |
| Description |
|
When we issue a command that contains a password through maxscale using xpandmon.
repro: example 1: CREATE USER
maxscale logs:
xpand logs:
example 2: BACKUP
maxscale logs:
xpand logs:
example 3: RESTORE
maxscale logs:
xpand logs:
|
| Comments |
| Comment by markus makela [ 2022-11-25 ] |
|
MaxScale does not know what the semantics of the SQL are and thus passwords will be logged if the SQL contains them in plaintext. The same limitation applies to all sensitive data routed through MaxScale. For the time being, I'd recommend not enabling the info log if the contents of the SQL are sensitive. |
| Comment by Johan Wikman [ 2022-12-08 ] |
|
log_info is not intended to be kept on during normal operation (e.g. it significantly affects the performance), but only to be used when debugging problems. When doing that it is often important to be able to see the statements verbatim. Further, masking only passwords is tricky as it requires explicit knowledge of all places where passwords can occur. So, do not have log_info on, unless there is an explicit need for that. When https://jira.mariadb.org/browse/MXS-3827 has been implemented, it will be possible to see after the fact whether someone has turned it on. Closing this now as Not a bug. If you think this is important, please create a feature request for "secure mode" that then would cause all functionality that potentially can reveal passwords (log_info, retain_last_statements, session_trace, possibly QLA filter, etc.) to be disabled. |