On Thu, 13 Mar 2025 at 13:19, Aditya Toshniwal < aditya.toshni...@enterprisedb.com> wrote:
> > > On Thu, Mar 13, 2025 at 4:54 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Thu, 13 Mar 2025 at 11:07, Aditya Toshniwal < >> aditya.toshni...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Thu, Mar 13, 2025 at 4:27 PM Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Thu, 13 Mar 2025 at 10:26, Aditya Toshniwal < >>>> aditya.toshni...@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Thu, Mar 13, 2025 at 3:36 PM Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, 13 Mar 2025 at 06:16, Aditya Toshniwal < >>>>>> aditya.toshni...@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> I have started looking into a feature where users have requested for >>>>>>> custom roles. The roles can then be assigned permissions. Here's what I >>>>>>> think how it can be done: >>>>>>> >>>>>>> 1. Create a framework for roles based access control. >>>>>>> 2. Allow adding/editing/deleting roles from UI. >>>>>>> 3. User management dialog can be converted to a tab to get extra >>>>>>> space for other stuff. >>>>>>> 4. pgAdmin can have some predefined permissions. The permissions >>>>>>> can then be used to validate at the API levels and UI. >>>>>>> 5. New permissions cannot be added from UI as it will require >>>>>>> code changes. They can be added based on user requests. >>>>>>> 6. Admin can allow these permissions to the roles and roles can >>>>>>> be assigned to users. >>>>>>> 7. Permissions will be used to >>>>>>> 8. Admin role remains static with no changes allowed. >>>>>>> >>>>>>> Let me know your thoughts on this. If everything looks good then I >>>>>>> will proceed. >>>>>>> >>>>>> >>>>>> What permissions would we support initially? >>>>>> >>>>> >>>>> Based on https://github.com/pgadmin-org/pgadmin4/issues/7310, we can >>>>> start with not allowing users to register a server. We'll start 1 or 2 may >>>>> be, the intention is to create a framework which will allow us to keep >>>>> adding permissions on future requests. >>>>> >>>> >>>> The reason I ask is that there's no point in creating a framework if we >>>> just end up with a single permission for adding/removing servers. I think >>>> it makes sense to be sure there are likely to be other permissions before >>>> committing to something likely to be a lot more complex than just adding an >>>> attribute to a user. >>>> >>> >>> I understand, but there have been many user requests for custom roles. I >>> agree that adding a complex thing like RBAC just for one single permission >>> is an overkill. But based on my past experience - users will come up with >>> more permissions once they see that they can tweak the permissions now. >>> What do you suggest we can do? >>> >> >> I do agree, there is the possibility for additional roles to come up, >> however, I'm struggling to think what makes sense right now. RBAC access to >> tools like psql or the Query Tool don't make much sense - if you can login >> to the database server, then there's nothing to stop you just running psql >> anyway and bypassing any RBAC we might implement. I suppose there might be >> an argument that pgAdmin is being used as a "gateway" to a server on an >> otherwise inaccessible network, but then I worry that that opens a whole >> other can of worms around locking down ways for users to execute queries >> through pgAdmin that we might never have previously considered to be a >> problem. >> >> You say there have been many user requests for custom roles. What roles >> were they asking for? >> > Roles similar to what Grafana provides > https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/, > but majorly restrictions around server nodes. > Many of those aren't relevant to pgAdmin, but one that did stand out is the ability to create/delete folders. That might well be useful to control. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com
