MySQL Bugs: #113124: ALTER or DROP USER commands should give a better error if user does not exist

Bug #113124	ALTER or DROP USER commands should give a better error if user does not exist
Submitted:	17 Nov 2023 14:30	Modified:	17 Nov 2023 17:02
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Security: Privileges	Severity:	S4 (Feature request)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	grants

Description:
I noticed this in some tooling:

node1 [localhost:21201] {msandbox} ((none)) > drop user 'does_not_exist'@'%';
ERROR 1396 (HY000): Operation DROP USER failed for 'does_not_exist'@'%'
node1 [localhost:21201] {msandbox} ((none)) >

node1 [localhost:21201] {msandbox} ((none)) > alter user 'fred'@'%' WITH MAX_USER_CONNECTIONS 100;
ERROR 1396 (HY000): Operation ALTER USER failed for 'fred'@'%'
node1 [localhost:21201] {msandbox} ((none)) >

In both cases it would be much cleaner to provide an error such as: "User does not exist".

Failure can occur for a number of reasons and anyone with DROP / ALTER permission should be able to see the reason that this fails. If they are not authorised to perform this action I believe they should get an error such as "User not authorised to perform this request". I'd guess such an error already exists.

How to repeat:
See the commands run on 8.2.0 from a box setup by dbdeployer.

Suggested fix:
- Improve the error message for both these situations and others where the failure is due to the user being modified not existing.
- If the user does not have the rights to make such a change provide the appropriate error message instead.

Context: automation managing grants for a system and a large number of users may see these errors and may not be able to determine the cause of the problem due to the imprecise error message from MySQL. A specific error message in this situation will allow the automation to handle 2 possible scenarios and be able to proceed based on the response it gets.

Hi Mr. Mudd,

Thank you for your feature request.

We think that it truly makes sense for the error message to be more clear. However, giving very precise error messages for the security features, might be harmful.

Hence, we shall investigate what can be done.

Verified.

OK. I would agree that if the user does not have the right to make the change then the current error message is fine.

For the user who does have the right to make the change hiding the actual problem is not helpful and I believe it makes sense to provide a more specific error.

From a documentation perspective it would be useful in https://dev.mysql.com/doc/refman/8.0/en/drop-user.html that you specify the errors the command can generate.  For someone who writes automation I would like to know which responses are possible and also handle failure scenarios. (I guess this comment has a broader scope than this specific command but you get the idea.)