Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.5, 10.6, 10.11, 11.4, 11.8
-
None
Description
Run with --view-protocol:
create user foo; |
grant all on test.* to foo; |
--connect (con1,localhost,root,,test)
|
SELECT CURRENT_USER() AS should_be_root; |
--change_user foo
|
use test; |
SELECT CURRENT_USER() AS should_be_foo; |
--connection default
|
DROP USER foo; |
main ab468e33aff110b44a31ce0350894906ff4bc757 |
connect con1,localhost,root,,test; |
SELECT CURRENT_USER() AS should_be_root; |
should_be_root
|
root@localhost
|
use test; |
SELECT CURRENT_USER() AS should_be_foo; |
should_be_foo
|
root@localhost
|
The reason is that MTR creates an extra connection to execute commands eligible for view-protocol when the first such command from a client connection is encountered (in this case, upon the first SELECT), and it keeps using the same connection even after change_user.
If we don't run the first SELECT when the user is still root, and change the user first, then MTR creates a new connection upon the other SELECT in the name of the right user, and it works.
With SET SESSION AUTHORIZATION introduced in MDEV-20299, the problem is even bigger, because MTR does not notice it even if the context is switched before the very first command, MTR still creates the extra connection in the name of the original user.
Attachments
Issue Links
- relates to
-
MDEV-20299 SET SESSION AUTHORIZATION
-
- In Testing
-