Hi Dave, On Mon, Mar 17, 2025 at 3:00 PM Dave Page <dp...@pgadmin.org> wrote:
> Hi > > On Mon, 17 Mar 2025 at 09:11, Aditya Toshniwal < > aditya.toshni...@enterprisedb.com> wrote: > >> Hi Dave, >> >> Essentially, the permissions can be based on the menus: >> >> Object Explorer >> >> 1. Manage Server Create/Edit/Remove. >> 2. Create database object (user could still be able to create using >> query tool) >> >> Definitely not the second one. We shouldn't do anything that is enforced > in the database server - it's unlikely the two permissions systems will > remain in sync for more than a few minutes, and we shouldn't be duplicating > server functionality anyway. > Yeah. So should I proceed with the implementation? > > >> Tools >> >> 1. Tool access like query tool, backup, etc. >> >> Storage Manager: >> >> 1. Create/Edit/Delete file. >> 2. Create/Edit/Delete folders. >> >> >> On Thu, Mar 13, 2025 at 8:47 PM Aditya Toshniwal < >> aditya.toshni...@enterprisedb.com> wrote: >> >>> >>> >>> On Thu, Mar 13, 2025 at 7:25 PM Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> 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. >>>> >>> >>> So we have 2-3 now. Let me dig in all the modules if I can find more >>> useful permissions. >>> >>>> >>>> -- >>>> Dave Page >>>> pgAdmin: https://www.pgadmin.org >>>> PostgreSQL: https://www.postgresql.org >>>> pgEdge: https://www.pgedge.com >>>> >>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* >>> <https://www.enterprisedb.com/> >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Thanks, >> Aditya Toshniwal >> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* >> <https://www.enterprisedb.com/> >> "Don't Complain about Heat, Plant a TREE" >> > > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* <https://www.enterprisedb.com/> "Don't Complain about Heat, Plant a TREE"
