Current plan level: Business
Monthly/Annual: Monthly
Version of Retool (if self-hosted): cloud
Question / Description:
I just upgraded to Business and deployed my first application. I created two user groups with different permissions to apps.
But I found a major flaw and security/data integrity concern for my use-case. The users can access the Retool database directly and edit the tables! With this access I can't ensure truth of the data and Retool becomes unusable for my company.
In the document: Configure permission controls | Retool Docs it says "Permission groups cannot be used to control access to Retool Database." Is this final and can't be changed? If so, it will make it very difficult for me to continue with Retool.
I discovered this today as well while I was looking through Retool Database's capabilities. Without being able to limit who can view/edit/own each DB Table, I don't see why I would use this tool over an API integration with Sheets or Airtable.
I've spent some time this afternoon playing around with custom permissions and have come to the conclusion that the line in the docs that you are referencing is a little misleading, if not outright incorrect.
A brand new, unmodified permissions group will not be able to view and edit RetoolDB via the GUI, nor will they be able to write queries that interact with it.
A group with "Use" level permission will still not be able to view and edit RetoolDB via the GUI, nor will they be able to write queries that interact with it - but they will be able to execute existing queries against that resource, assuming they have access to also read from the Query Library.
A group with "Edit" level permission will still not be able to view and edit RetoolDB via the GUI but they will be able to write and execute queries that interact with it.
Last but not least, only the "Own" level permission can view and update RetoolDB via the GUI while also having the ability to write and execute queries that interact with it.
Note that these permissions can also be configured separately for the production vs staging environments, giving you even more granular control.
I have tested all of the above and it seems to be working as expected. All that said, there is one big caveat - anybody with the connection string has full access to your database. That is why we only make it visible to users with the "Own" level permissions and visually obscure it, even then.
Hopefully this overview is helpful in understanding our custom permissions system! And you're not the first customer to ask about more granular per-table permissions, @jsifuen so, I will definitely pass that on to our internal team.
BUT there's one MAJOR problem here. I have a user set up with ONLY use permissions:
If I log in this account and the main site comes up I can see this:
I can click it and see the Retool database. I can edit ALL the tables as I please.
This is an absolute NO-NO!!! Or am I missing something here?
My guess is that you haven't yet configured the permissions for the "All Users" group, which is why this user still has access to RetoolDB and other features. If a user is a member of multiple groups, they will retain the highest specified level of access.
Double check that the user isn't a member of another permissions group and that you've reduced the permissions of the "All Users" group to "Use"!
I completely overlooked that the app settings for All Users was correct, but the Resources permission was set to "own all". Thank you for pointing that mistake out! Problem solved
