Bug #79304 | MySQL audit plugin receives bad row counts | ||
---|---|---|---|
Submitted: | 17 Nov 2015 6:29 | Modified: | 24 May 2018 7:28 |
Reporter: | Manuel Ung | Email Updates: | |
Status: | Analyzing | Impact on me: | |
Category: | MySQL Server: Security: Audit | Severity: | S3 (Non-critical) |
Version: | 5.6 5.7 8.0 | OS: | Any |
Assigned to: | Marek Szymczak | CPU Architecture: | Any |
[17 Nov 2015 6:29]
Manuel Ung
[25 Jan 2016 9:26]
Chiranjeevi Battula
Hello Manuel Ung, Thank you for the bug report. I could not see any issue in the user manual. Probably docs are changed recently. Thanks, Chiranjeevi.
[25 Jan 2016 17:43]
Manuel Ung
Quoting from the documentation: general_rows: For general query log events, zero. For error log events, the row number at which an error occurred. For result events, the number of rows in the result plus one. For statements that produce no result set, the value is 0. This encoding enables statements that produce no result set to be distinguished from those that produce an empty result set. For example, for a DELETE statement, this value is 0. For a SELECT, the result is always 1 or more, where 1 represents an empty result set. From reading the code, this value is never 0, contrary to the documentation. You can also try this yourself by running a DELETE statement. Also, this is what the expected output should be: select * from t where i = 0; => audit plugin receives row count of 1 (expected: 1) select * from t where i = 1; => audit plugin receives row count of 1 (expected: 2)
[24 May 2018 7:28]
Manuel Ung
This appears to be a problem in 8.0 still. Although documentation has removed mentions of general_rows (https://dev.mysql.com/doc/refman/8.0/en/writing-audit-plugins.html) I'm not sure what the intended use case of general_rows is, if queries that return 0 rows and 1 row both set general_rows to a value of 1?