You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mysql handles user grants and permissions differently than postgres so we'll need to implement this differently.
mysql has a table called - information_schema.table_privileges this holds all of the table privileges that the user has. The problem is that this table only shows explicit privileges. I.e. privileges that have been granted to the user via grant SELECT, INSERT, etc. on <schema>.<table> to <user>. It does not show inherited privileges.
We can also run show grants <user> to see what grants a specific user has. This will return something like:
GRANT SELECT, INSERT, UPDATE, DELETE ON . TO evis@%
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON user.* TO evis@%
GRANT SELECT ON user.testtable TO evis@%
In order to understand that tables a user has access to, we'd need to parse this table and understand the grants and then match that against the tables that we see in information_schema.tables to return the databases and tables that the user has access to.
Once we have all of this, we can then pipe this into the <Permissions /> component on the front end and render it there. Refer to the <Postgres /> component to see how we render this on the front.
mysql handles user grants and permissions differently than postgres so we'll need to implement this differently.
mysql has a table called -
information_schema.table_privileges
this holds all of the table privileges that the user has. The problem is that this table only shows explicit privileges. I.e. privileges that have been granted to the user viagrant SELECT, INSERT, etc. on <schema>.<table> to <user>
. It does not show inherited privileges.We can also run
show grants <user>
to see what grants a specific user has. This will return something like:GRANT SELECT, INSERT, UPDATE, DELETE ON . TO evis@%
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON user.* TO evis@%
GRANT SELECT ON user.testtable TO evis@%
In order to understand that tables a user has access to, we'd need to parse this table and understand the grants and then match that against the tables that we see in
information_schema.tables
to return the databases and tables that the user has access to.Once we have all of this, we can then pipe this into the
<Permissions />
component on the front end and render it there. Refer to the<Postgres />
component to see how we render this on the front.From SyncLinear.com | NEOS-924
The text was updated successfully, but these errors were encountered: