distal-attribute
distal-attribute
distal-attribute
distal-attribute

Deleting/renaming root account hides objects

Joselitux posted 2 years ago in General
Hello

First of all Thanks for such excellent software.
I've found an odd behaviour when deleting or renaming root account. (Creating a new account with same privileges than root named "whateveryouwant")

Latest versión to date (7.0 stable) if you delete or rename root account on a fairly used mysql server (many tables and databases) when login with the new root-like account can't see any of the previously created tables inside the databases, even when the new user has ALL PRIVILEGES. The tree shows databases but can't access to objects inside. No error is displayed, just a blank plain empty tree is shown.

Any other mysql client shows tables with no problem at all login with the new user (tested TOAD, mysqlWorkbench, dbeaver and sqldbx), so I think this is a heidisql issue

Steps to reproduce the issue (be carreful, don't do in a production server):

1- create a root-like account vía renaming root or cloning root account.
2- delete original root account
3- exit heidisql
4- login using the recently created root-like account
5- navigate through object tree
ansgar posted 2 years ago
Not reproducible here. What I did was clicking "Clone" on the root@127.0.0.1 user, on my local MySQL 5.5.8 server, gave it the username "ruth". Can log in with that user, see everything. The user creation looked as follows:

CREATE USER 'ruth'@'localhost';
GRANT EXECUTE, PROCESS, SELECT, SHOW DATABASES, SHOW VIEW, ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TABLESPACE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, INDEX, INSERT, REFERENCES, TRIGGER, UPDATE, CREATE USER, FILE, LOCK TABLES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHUTDOWN, SUPER ON *.* TO 'ruth'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ansgar posted 2 years ago
Ah, probably noticable: I'm not running Heidi 7.0 stable, but the latest build (7.0.0.4217).
ansgar posted 2 years ago
r3917 (pre-7.0 commit) fixed non-overtaken privileges when clicking the "Clone" button. But as you say you run 7.0 stable (= r4053) you should already have that fix.
Joselitux posted 2 years ago
would be very interesting to check if deleting root account (rather than clone) have that fixed too.

thanks
Joselitux posted 2 years ago
Tested with latest build (7.0.0.4217) deleting root account still suffering that issue

any hint?
ansgar posted 2 years ago
Please post the GRANT command which is executed during the click on "save" on the cloned user.
Joselitux posted 2 years ago
Hi folks!

the issue is when DELETING the root account, as noted in the procedure below. Not cloning. To be more specific:

1.- create a new account. Give ALL privileges.
2.- Delete root account
3.- exit heidi
4.- open heidi a create session with the new account
5.- Databasess show no data (0 B)
ansgar posted 2 years ago
And again, sigh: Please post the GRANT command which is executed during the click on "save" on the cloned user.
ansgar posted 2 years ago
... typo: not the cloned, but the new created user.
Joselitux posted 2 years ago
here:

GRANT EXECUTE, PROCESS, SELECT, SHOW DATABASES, SHOW VIEW, ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TABLESPACE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, INDEX, INSERT, REFERENCES, TRIGGER, UPDATE, CREATE USER, FILE, LOCK TABLES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHUTDOWN, SUPER ON *.* TO 'new_root'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ansgar posted 2 years ago
Ok, thanks. Just did exactly that (removed unsupported TABLESPACE, EVENT and TRIGGER for our old 5.0 server), and connected successfully. Can see everything, in all databases, all tables, no problem.
Joselitux posted 2 years ago
maybe it's an issue for 5.5 server only....

Please login to leave a reply, or register at first.