Tag Info

New answers tagged

2

I would choose Option 2 If you use Option 1 and revoke privileges, you have to put them back. The mysql grant tables are MyISAM. Should any crash, human error, or other unexpected event corrupt the tables, you have a mess to clean up. Only those with SUPER privilege can perform writes when read_only is enabled. SUPER is not a database-level grant. With ...


0

Aley, GRANT ALL ON my_db.* TO my_user@127.0.0.1; is a superset of: GRANT SELECT, INSERT, UPDATE, DELETE ON my_db.* TO my_user@127.0.0.1; So the last one is superfluous. You must understand that SHOW GRANTS do not show every grant query that you executed, and that in some specific cases, it may not show all grants for a user. That is something that can ...


5

From here If you have the PROCESS privilege, you can see all threads. If you have the SUPER privilege, you can kill all threads and statements. Otherwise, you can see and kill only your own threads and statements. You can also use the mysqladmin processlist and mysqladmin kill commands to examine and kill threads. See here for privilege ...


2

Also addressing the question in the comments. Role public Per documentation: The key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles. Bold emphasis mine. Membership in public cannot be ...


1

To address the question of why test can SELECT from tables without a GRANT, it is because you have not explicitly run REVOKE for the ability to connect to your database(s) from PUBLIC, and then explicitly run GRANT for your test user: REVOKE connect ON DATABASE testdb FROM PUBLIC; GRANT connect ON DATABASE testdb TO test; Once that is done, you would ...



Top 50 recent answers are included