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 1tsggH-004dYo-L6 for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 11:24:53 +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 1tsggG-00BAA0-15 for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 11:24:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tsggF-00BA9s-ON for pgadmin-hackers@lists.postgresql.org; Thu, 13 Mar 2025 11:24:51 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tsggB-002dfN-2b for pgadmin-hackers@postgresql.org; Thu, 13 Mar 2025 11:24:51 +0000 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-548409cd2a8so949149e87.3 for ; Thu, 13 Mar 2025 04:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1741865088; x=1742469888; 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=IHgrhefl4JO1AZP0VYGSFSRl1eRub1Uujc2sMxhMEGw=; b=Q32dTf4trQltvsCvPtoE13qhrZDEXFz1BmWuBlIlIQw7Qvch/fx+qd61ax6drSMC/S vfwPPD9WPkJ/8lTws522riA3yv2iZ2umlnTpPcWVH9qvcoG674T7huQe1FtQfa1ymzra M6lleUcs9cAKA9NVzybAKwF3uN14EY6YJwrT0Q5pg1VRhuGRwQou6r4F1eNSHRCTgiih yMQjrTyp4QUZ9zZnVixcf3g88VTC0gxAu0I2cLEo2+ZnaEr/KE00RMQE+bs8UeaXMTn7 /LyUTSqAFV/WjNYAyxhz6Fsb4yFeykBEiWPC1vTYeZIfGqqHOi1sPvfMdJPZqBdIZ+9n MS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741865088; x=1742469888; 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=IHgrhefl4JO1AZP0VYGSFSRl1eRub1Uujc2sMxhMEGw=; b=vggGqZFdDhTqq2Ss55mU/Sl6IIAG9JYBjB24bEHEwUgZRH4s4gA8uDwqSMiYx3b3D1 tonnNB1ZgCogn5uhk0+l9J3a1z8K4NCrJ5A5qIeXbwTktQycgtci5RS0158zlhJY3yve 17yrZJTZDFUPxO3hurnNzrd6QTfqG8AUIHkgRndEmCbpzCzKhvnlj+QrtP5yc9Vc7jcU h7+7LYn5pVowNopMo+bEWJ8dCggIjhmzB8UdFDxzDt+yxEdBX2ZI7RoAMoxXNEerN9ri qdWEShPmKsvFxzNv8UFA96sIVJrbAJDxTEC9DzK/0CR/zrnQSJONboJn7CTZm60fjYqQ UsYg== X-Gm-Message-State: AOJu0YyH5a1raFDpbyzI0Qk4Uafm3J49U4sKS5DXeWN4ExI1QSk24AWI EGehIL64VvcmhBtlADcp4NWwZ096t53BYShb8ueslhga48yxGcSOBTPospAM2WK0wuNArgTCFNM uTt4tLGuBIdstLEmYDlZ9veVArXHkofnzqDWCPxTapPVnMXxpmQ== X-Gm-Gg: ASbGncs5/vs5yhJBu9RKXxoTXuQGl/z9MXiYUhOPRzNYXIo5DZrXnUPTgGbqYAl1VWG m1mRL4aVnCzSTB6UymsBXGn6bLojC/AeWRAmJfuydrQV8hH6NnI2FU06EvyFQHp0AxHimhFKooo pzzCKHtdKDjK9hgpBKkkyOEekwEDVg X-Google-Smtp-Source: AGHT+IEvw56md9Zyl99k1uHx11onI/Al/dVt5AIOooKgkg8hsf4sCCW7trlcnernw5SfMThBk7tg0KwqFXazhU0RbqA= X-Received: by 2002:a05:6512:2313:b0:549:8d07:ff13 with SMTP id 2adb3069b0e04-54990ec8f36mr9386195e87.51.1741865088128; Thu, 13 Mar 2025 04:24:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Thu, 13 Mar 2025 11:24:37 +0000 X-Gm-Features: AQ5f1Jp3RJBYJmEMaxoLdWaY0uJutddGklqWNCozTyRotbaRLp_UOjFviFBARLs Message-ID: Subject: Re: Role based access control discussion To: Aditya Toshniwal Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000d339f306303791f6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d339f306303791f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wro= te: > >> >> >> 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 w= rote: >>> >>>> 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 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 thin= k >> it makes sense to be sure there are likely to be other permissions befor= e >> 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 permissio= n > 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? --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --000000000000d339f306303791f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 13 Mar = 2025 at 11:07, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi=C2=A0Dave,

=
On Thu, Mar 13, 2025 at 4:27=E2=80=AF= PM Dave Page <dpa= ge@pgadmin.org> wrote:


On Thu, 13 Mar 2025 at 10:26, Aditya Toshniwal <aditya.to= shniwal@enterprisedb.com> wrote:
Hi= =C2=A0Dave,

On Thu, Mar 13, 2025 at 3:36=E2=80=AFPM Dave Page <dpage@pgadmin.org>= ; wrote:
Hi
On T= hu, 13 Mar 2025 at 06:16, Aditya Toshniwal <aditya.toshniwal@enterprisedb.co= m> wrote:
Hi Hackers,

I have started looking into a feature where users have requested for c= ustom 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 b= e converted to a tab to get extra space for other stuff.
  4. pgAdmin ca= n have some predefined permissions. The permissions can then be used to val= idate at the API levels and UI.
  5. New permissions cannot be added fro= m UI as it will require code changes. They can be added based on user reque= sts.
  6. Admin can allow these permissions to the roles and roles can b= e assigned to users.
  7. Permissions will be used to=C2=A0
  8. Admi= n role remains static with no changes allowed.
Let me know yo= ur thoughts on this. If everything 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 us= ers to register a server. We'll start 1 or 2 may be, the intention is t= o create a framework which will allow us to keep adding permissions on futu= re 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 sen= se 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.
=C2=A0
I understand, but there have been many user requ= ests for custom roles. I agree that adding a complex thing like RBAC just f= or 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.
Wha= t do you suggest we can do?

I do agree, there is the possibility=C2=A0for additional roles to come u= p, however, I'm struggling to think what makes sense right now. RBAC ac= cess to tools like psql or the Query Tool don't make much sense - if yo= u can login to the database server, then there's nothing to stop you ju= st 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&q= uot; to a server on an otherwise inaccessible network, but then I worry tha= t 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 cons= idered to be a problem.

You say there have been ma= ny user requests for custom roles. What roles were they asking for?
=C2=A0--
<= div dir=3D"ltr" class=3D"gmail_signature"> --000000000000d339f306303791f6--