Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tsj2K-00524k-KN for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 13:55:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tsj2I-00EHLq-W1 for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 13:55:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tsj2I-00EHLi-GK for pgadmin-hackers@lists.postgresql.org; Thu, 13 Mar 2025 13:55:46 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tsj2F-002cjS-2Q for pgadmin-hackers@postgresql.org; Thu, 13 Mar 2025 13:55:45 +0000 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5498d2a8b89so1050338e87.1 for ; Thu, 13 Mar 2025 06:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1741874142; x=1742478942; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8bb1Xyu3GR9HJ9sct0JfObB2bSx7WbxN9PCiHC7OmB4=; b=FqRjoyA2mOwgT06AuY1SVqv4+TQXEnIg1d9C3y9bp8KW+ZanWR+ZDcsM5kcqBdWmko a+UnF03uWcOm1HPLVWTq8yrXVlFnVVPernoZUI5nO1l6q0VE19egkmMMmvVUW2sYjpv9 u6QNkra5IVDNFrKy1F1DY9OAPIMvEde6YIsUQ0rNJCxCGzOBIH+BmBgSceBw16wJEu2+ Y/ycKbpPh+MF26h4XaIPg8fFYAefgzPsr/DiLUHcGW2avf/NVW4JFokTL/a1E5EJsVmn RMEq8EeiIaxdNmbSongEVH2MAEPtFI6EjcIl3/KhcViAvDn2ZHf3EFIqVSiKTrp8adTg u2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741874142; x=1742478942; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8bb1Xyu3GR9HJ9sct0JfObB2bSx7WbxN9PCiHC7OmB4=; b=cGzWpdA3BnsbLxSQ2PA1CeRyqzVOxrikuX+vYQCk3MS5XIu9l5UXAWkgNfi9wNv2iy itlbNRlS5QzxBinzRFibl9qrlcC1zOjSUSOW6uuDPTtd8264A22LChwh/l1HSilNIz/Q 1SJSDT+qtXmX/Kev2sbyYEHtdQnsDTV/EjnesOGAMu/nh8bzb+2lw+H9tB1FN1czY2XY SCzX1c4SagVjd1zgiOPJOQHyfc8VUCcPAbF2caW21NUTlbk1DuK2UQvIjzbQkWiNG29U EwdqsJ6HCjJ0zSzKLIYJpCKqfnd6k5KQvlcgrv/T2mX/RWorLgjB6tx22pZcg9+fO1zl S7vA== X-Gm-Message-State: AOJu0YziL1aRqY1LLJeloT7WeN/kiy/Bq8Kmsuqj2Bgk+sV0dYsAGA4Z HRnKDoytsLT3KPmdebRMFSTC+0dRX89FuWo8u8SWUEevJFvSldcfa2C4ISYt5HRfCb17QuKnNfT f0LtX2cm1eOc500w5pNZGeIhJKSdNRXqzpr8z X-Gm-Gg: ASbGncte4hdPpChTCZ65VUHAPTAOftcE19tKnhzyfiYg3LOy65YtM9kaWU+pOP+VhNt IF1D6qLTsmHhtW7RuZQ4u4Nog4TOvOtU2pGYWE0nnr5A16A0fU7itjiIugJ0c51KrDKSEt4/teq o4/Uynu6dTOu5N8ZfKiH/sCOz6zoam X-Google-Smtp-Source: AGHT+IEmiqs3RVJKLZVAudv5VzKLsatq/A3hKBKaqJ80jy+VV/6lvkujIDV+xut4wLkZoUa1a9ajxLnzEkCkI6oF//Y= X-Received: by 2002:a05:6512:3ca0:b0:549:69da:cb96 with SMTP id 2adb3069b0e04-54990ec9640mr9565484e87.52.1741874141922; Thu, 13 Mar 2025 06:55:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Thu, 13 Mar 2025 13:55:31 +0000 X-Gm-Features: AQ5f1JqBimhOD0hL8Cwfp8ny2oTB0rdXNPmfNlKijfEjlayN0YApkJ2EBxVp5BY Message-ID: Subject: Re: Role based access control discussion To: Aditya Toshniwal Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000792777063039adbe" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000792777063039adbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 13 Mar 2025 at 13:19, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > > > On Thu, Mar 13, 2025 at 4:54=E2=80=AFPM Dave Page wro= te: > >> >> >> On Thu, 13 Mar 2025 at 11:07, Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Thu, Mar 13, 2025 at 4:27=E2=80=AFPM Dave Page w= rote: >>> >>>> >>>> >>>> On Thu, 13 Mar 2025 at 10:26, Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Thu, Mar 13, 2025 at 3:36=E2=80=AFPM Dave Page = wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, 13 Mar 2025 at 06:16, Aditya Toshniwal < >>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> I have started looking into a feature where users have requested fo= r >>>>>>> custom roles. The roles can then be assigned permissions. Here's wh= at 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 kee= p >>>>> adding permissions on future requests. >>>>> >>>> >>>> The reason I ask is that there's no point in creating a framework if w= e >>>> just end up with a single permission for adding/removing servers. I th= ink >>>> it makes sense to be sure there are likely to be other permissions bef= ore >>>> committing to something likely to be a lot more complex than just addi= ng 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 permiss= ion >>> is an overkill. But based on my past experience - users will come up wi= th >>> 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 log= in >> to the database server, then there's nothing to stop you just running ps= ql >> 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-permissi= ons/, > 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --000000000000792777063039adbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 13 Mar = 2025 at 13:19, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:


On Thu, Mar 13, 2025 at 4:54=E2=80=AFPM Dave = Page <dpage@pgadm= in.org> wrote:


On Thu, 13 Mar 2025 at 11:07, Aditya Toshniwal <aditya.toshniwa= l@enterprisedb.com> wrote:
Hi=C2=A0Da= ve,

On Thu, Mar 13, 2025 at 4:27=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:=


=
On Thu, 13= Mar 2025 at 10:26, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com&= gt; wrote:
Hi=C2=A0Dave,

On Thu, Mar 13= , 2025 at 3:36=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, 13 Mar 2025 at 06:16, Adity= a Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Hackers,

I have started looking int= o 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 fo= r roles based access control.
  2. Allow adding/editing/deleting roles f= rom UI.
  3. User management dialog can be converted to a tab to get ext= ra space for other stuff.
  4. pgAdmin can have some predefined permissi= ons. 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 ch= anges. They can be added based on user requests.
  6. Admin can allow th= ese permissions to the roles and roles can be assigned to users.
  7. Pe= rmissions will be used to=C2=A0
  8. Admin role remains static with no c= hanges allowed.
Let me know your thoughts on this. If everyth= ing looks good then I will proceed.

What=C2=A0permissions would we support initially?

Based on=C2=A0https://github.com/pgadmin-org/pgadmin4/issues= /7310, we can start with not allowing users to register a server. We= 9;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.
<= /blockquote>

The reason I ask is that there's no poi= nt in creating a framework if we just end up with a single permission for a= dding/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 m= ore complex than just adding an attribute to a user.
=C2=A0
I un= derstand, 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 pe= rmissions once they see that they can tweak the permissions now.
What do you suggest we can do?

I do agree, there is the pos= sibility=C2=A0for 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 ser= ver, then there's nothing to stop you just running psql anyway and bypa= ssing any RBAC we might implement. I suppose there might be an argument tha= t pgAdmin is being used as a "gateway" to a server on an otherwis= e 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 pgAd= min that we might never have previously considered to be a problem.

You say there have been many user requests for custom rol= es. What roles were they asking for?
Roles similar to what Grafana pr= ovides=C2=A0https://grafana.com/docs/grafa= na/latest/administration/roles-and-permissions/, but majorly restrictio= ns around server nodes.

=
Many of those aren't relevant to pgAdmin, but one that did stand o= ut is the ability to create/delete folders. That might well be useful to co= ntrol.

-- =
--000000000000792777063039adbe--