On Mon, Mar 17, 2025 at 3:39 PM Dave Page <dp...@pgadmin.org> wrote:
> Hi > > On Mon, 17 Mar 2025 at 09:39, Aditya Toshniwal < > aditya.toshni...@enterprisedb.com> wrote: > >> 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? >> > > > If that’s what Akshay wants you working on, then sure :-) > I was waiting for confirmation if the pgAdmin team would accept it or not :) > > >>> >>>> 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" >> > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* <https://www.enterprisedb.com/> "Don't Complain about Heat, Plant a TREE"
