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 1tsgPl-004Zk9-UF for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 11:07:50 +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 1tsgPk-00AqXz-IG for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 11:07:48 +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 1tsgPk-00AqSM-80 for pgadmin-hackers@lists.postgresql.org; Thu, 13 Mar 2025 11:07:48 +0000 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tsgPg-002dYN-24 for pgadmin-hackers@postgresql.org; Thu, 13 Mar 2025 11:07:47 +0000 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-86b9d1f729eso355597241.3 for ; Thu, 13 Mar 2025 04:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1741864064; x=1742468864; 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=8h7xodIxUI2kj0pYG/ZriEae3dfcGs5xLe59QFjFfmY=; b=fEFyg2SGHLgyV1Hmm8WRhr6Kl2xPAs62n0mUJxDY3ROo3RBtSKF5V7oZ3D784QU9Qu +UMaUSPowco1Zdxhulpne+wkr+S0ja26dUx2Ikovym/85cbERxmqBcSuj4YLBOi9RpVl iA9qfVsZjAqPpKIaWHOH8pNCWqXMlfEHXOB+pX1Ftu+7gG6DVzGAEuweOhA0kfOgqslP 6G6TTxLmB/SHspnFgUfVhI20dvRV1hOIaMADqIFy06MpUXhR11N0Zu4Y/VyKGx15RM19 BhZLuHQUxx9i3UC1uB6Df4AX2Ki0+6Qq/ST4jsTHZpeebhS47vbCstmIdFdQOeDHTEkY wnfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741864064; x=1742468864; 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=8h7xodIxUI2kj0pYG/ZriEae3dfcGs5xLe59QFjFfmY=; b=q5aimetTtmTFFMMfWouDvqVXnf0R4ULC3Zs2M9fggv63ImQyFB3ZoDPfafEPGNfXoO 987Nwrs2M2R4jXhkMOvrTuhftm9EMvS7pUVMtmZ+SxC8ww7wjYDy/8YRDy7m46CTIloF NvF6JqDOLXg89r6Kq6BpHkXkAGpVb3UlT2pXbmxmLmG2r6ov/8VE+1qVxhK7mFuQYAvF dfAZ2YHYuYM6SjXDIQu5mM9QvFVFTJ3LT4+7kSfcFN/zIo9vRW9Gf37CKOaTbYDE2PLy nklewI8vDEkyft6SPMUUr+3tFPEluj/cumg33rho7x4/h0OOa05QvqMTg0FU91INc9mP R3RA== X-Gm-Message-State: AOJu0YzwNbwvRTvVpcMiHIHfs8tPIhJPrROYvHqTj6czNIZhCxSy6Cbx rmm6ikPDN36XiwfsAgBLMJibWE94INf9Rusc9v4kGsmeSZjwr1bKtyfOfvaYmoHlwi3vyTtMQqG N4IF3O16kpnS6uOllyJrbo/BwsTcMWihZPU7h X-Gm-Gg: ASbGnctVG0l7gF+SYkeAceyGhXcei+G1ynBW7p25UxSm+AdfKEPirVHGn80kkG0LyAD 9RmSn+FhHeAAKy4j99wwurts4Wbidpwxkg4JqwN9g6EG+8MsDdDaPKDC01C7e6mIl30vsJ/mZyJ gXQJM6Mmr1jlfrMcz+9oBPiQGvQbWCexcmQwM5hir6ne5O2S7/vomUWWst02Fc X-Google-Smtp-Source: AGHT+IEn8t3qL/9vIP5rp9zfr+AhGksB96DlCRhPXOK7UUU1YcoQI+kQd17SOiCZ6qXKVz0WBjOo6+qJMYI43682Phw= X-Received: by 2002:a05:6122:310c:b0:51f:3eee:89f4 with SMTP id 71dfb90a1353d-523e4174e58mr18925240e0c.9.1741864063586; Thu, 13 Mar 2025 04:07:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Thu, 13 Mar 2025 16:37:07 +0530 X-Gm-Features: AQ5f1JqPF86XLbLWNuQkoDxjORJdrXG2YsZX41oyJhHubxFsA0jBbeL3RfplCxc Message-ID: Subject: Re: Role based access control discussion To: Dave Page Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000c20b4706303754fd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c20b4706303754fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, On Thu, Mar 13, 2025 at 4:27=E2=80=AFPM Dave Page wrote= : > > > 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 wr= ote: >> >>> 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 wil= l >>>> 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 m= ay >> 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? > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000c20b4706303754fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Dave,

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

On Thu, 1= 3 Mar 2025 at 10:26, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com= > wrote:
Hi=C2=A0Dave,

On Thu, Mar 13, 2025 at 3:36=E2=80=AFPM Dave Page <<= a href=3D"mailto:dpage@pgadmin.org" target=3D"_blank">dpage@pgadmin.org= > wrote:
Hi

On Thu, 13 Mar 2025 at 06:16, Aditya Toshni= wal <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 conv= erted 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 a= s 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 assi= gned to users.
  7. Permissions will be used to=C2=A0
  8. Admin role= remains static with no changes allowed.
Let me know your tho= ughts on this. If everything looks good then I will proceed.

What=C2=A0permissions would we su= pport initially?

Based on=C2=A0https://github.com/pg= admin-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 crea= te a framework which will allow us to keep adding permissions on future req= uests.

The reason I ask i= s 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 somet= hing likely to be a lot more complex than just adding an attribute to a use= r.
=C2=A0
I understand, but there have b= een many user requests for custom roles. I agree that adding a complex thin= g 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 th= at they can tweak the permissions now.
What do you suggest we can do?
=
=C2=A0
--


--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"
--000000000000c20b4706303754fd--