BUG#13864642: DROP/CREATE USER BEHAVING ODDLY
BACKGROUND: In certain situations DROP USER fails to remove all privileges belonging to user being dropped from in-memory structures. Current workaround is to do DROP USER twice in scenario below OR doing FLUSH PRIVILEGES after doing DROP USER. ANALYSIS: In MySQL, When we grant some stored routines privileges to a user they are stored in their respective hash. When doing DROP USER all the stored routine privilege entries associated with that user has to be deleted from its respective hash. The root cause for this bug is some entries from the hash are not getting deleted. The problem is that code that deletes entries from the hash tries to do so while iterating over it, without taking enough measures to address the fact that such deletion can reshuffle elements in the hash. If the user/administrator creates the same user again he is thrown an error 'Error 1396 ER_CANNOT_USER' from MySQL. This prompts the user to either do FLUSH PRIVILEGES or do DROP USER again. This behaviour is not desirable as it is a workaround and does not solves the problem mentioned above. FIX: This bug is fixed by introducing a dynamic array to store the pointersto all stored routine privilege objects that either have to be deleted or updated. This is done in 3 steps. Step 1: Fetching the element from the hash and checking whether it is to be deleted or updated. Step 2: Storing the pointer to that privilege object in dynamic array. Step 3: Traversing the dynamic array to perform the appropriate action either delete or update. This is a much cleaner way to delete or update the privilege entries associated with some user and solves the problem mentioned above. Also the code has been refactored a bit by introducing an enum instead of hard coded numbers used for respective dynamic arrays and hashes in handle_grant_struct() function.
Showing
This diff is collapsed.
Please register or sign in to comment