MySQL Bugs: #20402: DROP USER failure logged as ERROR rather than WARNING

Bug #20402	DROP USER failure logged as ERROR rather than WARNING
Submitted:	12 Jun 2006 15:45	Modified:	14 Sep 2006 2:49
Reporter:	Matthew Lord	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Errors	Severity:	S3 (Non-critical)
Version:	4.1.20	OS:	Any (all)
Assigned to:	Timothy Smith	CPU Architecture:	Any

Description:
DROP USER failure logged as ERROR rather than WARNING
e.g.

060612  9:58:09 [ERROR] DROP USER: Can't drop user: 'foo'@'localhost'; No such user 

I could not repeat this behavior using 5.0.22.

How to repeat:
mysql -u root
drop user foo@localhost;

tail /usr/local/mysql/*.err

Suggested fix:
This should be logged as a WARNING and only printed if log-warnings is enabled.

testless patch

Attachment: bug20402.patch (application/octet-stream, text), 520 bytes.

This is not a bug; rather, it is intended behaviour designed to avoid 
a potential security breach. To quote Jim Melton, the editor of the SQL standard:
"The general philosophy in SQL is to hide information about schema
objects from users who don't have any privileges to use those objects.
For example, if there were a table named EMPS_TO_BE_FIRED, knowledge
of its existence would probably upset current employees. Therefore, you 
want the same error to be returned from SELECT * FROM EMPOLYEES
(if no table with that misspelled name exists) as from SELECT * FROM
EMPS_TO_BE_FIRED when you don't have any privileges on EMPS_TO_BE_FIRED.
If you returned "No such table" from one and "No privileges on table"
from the other, you will have admitted that such a table exists, which
raises a security issue. Consequently, SQL:1999 says, "Either no such 
table exists or you have no security privileges on the table" (or words 
to that effect)."

For DROP USER, MySQL follows this philosophy and also follows the 
Standard's requirement that such diagnostics be returned as an error 
and not a warning.

Other places where sql_print_error() may be used incorrectly: 

sql/slave.cc|2949| sql_print_error("Slave SQL thread stopped because it reached its"
sql/sql_acl.cc|3672| sql_print_error("DROP USER: Can't drop user: '%s'@'%s'; No such user",
sql/sql_acl.cc|3680| sql_print_error("DROP USER: Can't drop user: '%s'@'%s'; Global privileges exists",
sql/sql_acl.cc|3703| sql_print_error("DROP USER: Can't drop user: '%s'@'%s'; Database privileges exists",
sql/sql_acl.cc|3726| sql_print_error("DROP USER: Can't drop user: '%s'@'%s';  Table privileges exists",
sql/sql_acl.cc|3794| sql_print_error("REVOKE ALL PRIVILEGES, GRANT: User '%s'@'%s' not exists",

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/9621

Patch looks ok to me

Available in 5.0.25

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/10791

ChangeSet@1.2536, 2006-08-23 15:37:54-06:00, tsmith@siva.hindu.god +2 -0
  Bug #20402: DROP USER failure logged as ERROR rather than WARNING
  
  Remove some sql_print_error() calls which were triggered by user error (i.e., not server-level events at all).
  
  Also, convert an sql_print_error -> sql_print_information for a non-error server event.

Pushed to 5.0.25

Noted in 5.0.25 changelog.

Some user-level level errors were being written to the server's error 
log, which is for server errors.

Pushed to 5.1.12

Noted in 5.1.12 changelog.