![]() There seems to be some issue with your user creation. I was also able to configure the CaptureChangeMySQL processor to capture changes without any other privileges being granted: Type '\c' to clear the current input statement. Other names may be trademarks of their respective ![]() Oracle is a registered trademark of Oracle Corporation and/or itsĪffiliates. Server version: 8.0.26 Source distributionĬopyright (c) 2000, 2021, Oracle and/or its affiliates. I tested the exact same commands that you specified above and I was able to connect to the database from the command line: ~]# mysql -u replication -p What I meant is that the CaptureChangeMySQL act as a replication client, and needs the same privileges as one. If this is by design, the documentation would benefit from list of all privileges which exhibit the same behavior as the CREATE privilege to unexpected errors.Don't need a MySQL replication server. Only CREATE privileges exhibit this behavior. This doesn't happen with global grants on the user or the role, neither with SELECT privileges on database. `joe_role` with the **very same** grants as the user, when assigned to the user, prevents them from creating database. | GRANT ALL PRIVILEGES ON `joe_db`.* TO | Just to be clear, I let me give you a brief example on what am I complaining about and what doesn't make sense to me: It sounds like a bug to me but if that's by design, my personal opinion is that the refman should have an enumeration of privileges which are assigned to a role on granting ALL privileges. It would be great if the documentation mentioned that granting ALL privileges for a role doesn't actually grant ALL privileges, but just some. Michael Bausano Thank you for your quick response. Since I couldn't find it in the manref, I suspect it's a bug.ĮRROR 1044 (42000): Access denied for user to database 'joe_db'įor the sake of eliminating other issues, let's see what happens when we set joe privileges to global. Doing this will prevent us from creating a database. Let's login as joe again and activate the joe_role. Mysql> GRANT `joe_role` TO OK, 0 rows affected (0.01 sec) Mysql> GRANT ALL ON `joe_db`.* TO `joe_role` We grant the very same privileges to this role as we do on Then we grant joe_role to joe. Now let's login as root again and create a new role joe_role. ![]() Now for the sake of eliminating other issues I log in as and assert that my grants indeed work. Mysql> GRANT ALL ON `joe_db`.* TO OK, 0 rows affected, 1 warning (0.02 sec) Mysql> CREATE USER OK, 0 rows affected (0.01 sec) While I omit the second step in my code, I use it here to illustrate how unexpected this behavior is. I use a MySQL 8.0.18 Docker image.įirst we create an actual user and grant it all privileges on joe_db. Revoking the role or granting global privileges make allow the user to be able to create the database again (although neither are viable workarounds). However when that same user is granted a role which has also all privileges upon a database, the user has no longer authority to create the database. When a user is granted all privileges upon a database, they can create the database. Therefore I attribute that behavior to a bug. I noticed a strange behavior which I couldn't find documented anywhere when granting roles to users. I use roles to give grants to my MySQL users.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |