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 1tut9t-00DQyv-GO for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 13:08:33 +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 1tut9r-004GHH-U7 for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 13:08:31 +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 1tut9r-004GH7-Kp for pgadmin-hackers@lists.postgresql.org; Wed, 19 Mar 2025 13:08:31 +0000 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tut9n-003lCI-1Z for pgadmin-hackers@postgresql.org; Wed, 19 Mar 2025 13:08:30 +0000 Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-547bcef2f96so7581618e87.1 for ; Wed, 19 Mar 2025 06:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1742389708; x=1742994508; 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=06JMzG8kmMDL1MBN4lwOlHYnZcLd/fX8QNWmzRicjQQ=; b=pE7dhjYGwtQGHx19wI4IbXaYocBFUbSZ1MdiaCNfp+AAX2I7WLHuf8UtwZ04jTJ/Yy x7dHYQinQVvCWwkOIBw8LsVyPigM9tgnrjanl/UzwG3tNw+7opz46hQx7sZtF7HB1s4t hky+1GiElKPyf8fOrokMioUIEiGMxanxMjYdG4637EDr01X1zhlyO8Z+qQBzivY/q56k Nt/Dso5ztGqyWjK9BGkni0vJimhPFYHc2rAiIu3NS67APkzdTaw80S256MFu4d+h4tT5 HEMPnrmLRCosxNlWt0Arj+zXdxX7rxx8Oj25cdU6q/UAMEjlg/Cvbfwr++StxXeL7VwY b8uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742389708; x=1742994508; 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=06JMzG8kmMDL1MBN4lwOlHYnZcLd/fX8QNWmzRicjQQ=; b=jGUK3O7j4/ustQ++xWUiLlQhvPVUDSGIKuwxDFxIF6u64gu9xs3WCtk1dWAES81qtZ 9nq8dxIhsMYcx62UgEpYRL8V7A4HTFoFNhMzhRydIz34pyUBMkMrsA4/L3uezTShFm9V V3WxfeUb9wAuY483LWyXF1tfKEgSIQRrbxR9GAMVuMAeY0pIaS62/w2oWlx2BalPQpp0 9Ja3sO72Jg5/9R1ryIhQloynff4qUmKk5WbBAbrO406r+KM7YxcovoxYBY+EfC7KF3AJ qLq47XcboYaIZqo67xLlDWjalqOJV73Cihb/HPHvfiqLVXsDhd8wg163GpyF+lapS/Ga FgiQ== X-Gm-Message-State: AOJu0Yx4mYp8Sy5WvasCwTiAo/XyamMDZ+Tye4lo3n+9Jt4qGjeG/dYK DU+VVW4Gjrs0t6v2iA1PtJD+2PvTRTe7tELBpCuR1+pvuOo/Ew1ByBL0NoiVbKRHO281qATOso0 X0/o4tY7ZXtpWqxmCB6esmHCsfAFJqZu5rYmSdxi1FxD+dNkfcw== X-Gm-Gg: ASbGncsgDxjgh990Zie9OLfAffBBUBPVpv0z20StXUoyJdwPtS9CVX0IMcdNtxUtM3K jWENgNklyY5XiGS1tieb0r7MFta3pGgVdp0l00r4xh+VkXHZMzCh9ocFonZEcyhgHpfFVSTQHp7 zF5dzYZ7zUkBvTzTK91qBjuC7pkhy0 X-Google-Smtp-Source: AGHT+IHhcLa+6jK9AO5OfCM6Nzgi3GktKiIRgsURff4W1n4VHvqIBJpUq+/CmuzwqB3wXHCGKG+iHdcCxFBp+5OkPp8= X-Received: by 2002:a05:6512:2396:b0:545:2e85:c152 with SMTP id 2adb3069b0e04-54acb20550fmr880693e87.34.1742389707886; Wed, 19 Mar 2025 06:08:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 19 Mar 2025 13:08:16 +0000 X-Gm-Features: AQ5f1JqlanrBcTejS8U9njKT77EJNQWNqMpnD-ts_hsMGnBRH5O7XWo_Onv9_7c Message-ID: Subject: Re: Regarding Feature #5305 To: Akshay Joshi Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000009974d00630b1b76e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000009974d00630b1b76e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 19 Mar 2025 at 12:42, Akshay Joshi wrote: > > > On Wed, Mar 19, 2025 at 5:11=E2=80=AFPM Dave Page wro= te: > >> >> >> On Wed, 19 Mar 2025 at 11:12, Akshay Joshi >> wrote: >> >>> Hi Dave/Hackers, >>> >>> I have started working on the feature #5305 >>> . Based on my >>> understanding, the Object Explorer should only display nodes or objects >>> where the currently logged-in user has at least one permission granted = in >>> the ACL. In other words, the user must have some level of access to eac= h >>> object displayed. >>> >>> For example, consider two users: 'postgres' (the default user) and >>> 'test'. There are objects, such as a table, where the 'test' user does = not >>> have any permissions. This table was created by the 'postgres' user, wh= o >>> has revoked all permissions for other users. Now, if the 'test' user lo= gs >>> into the database server, we need to check whether the logged-in user h= as >>> any permissions on the object. If not, it should not be displayed in th= e >>> Object Explorer. >>> >>> We will have a preference for whether to apply this check or not. There >>> are following two solutions that can be implemented: >>> 1) Change the *nodes.sql* to filter out the nodes based on privileges. >>> It's challenging, as I tried with aclexplode(relacl), unnest(relacl) in= the >>> WHERE clause, and other different attempts to filter out Table nodes, b= ut >>> seems we will find some solution for sure). >>> 2) Once nodes are fetched then filter out the data at the backend. >>> >>> Any other solution or suggestion? >>> >> >> This seems like it would be a very large amount of work, for very little >> gain, and would certainly be inconsistent with how we would expect to >> browse files and folders for example. I do not think it is worth the eff= ort. >> > > OK Thanks, So should we keep this feature request open or close it? > I'd close it. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --0000000000009974d00630b1b76e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 19 Mar = 2025 at 12:42, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:


On Wed, Mar 19, 2025 at 5:11=E2=80= =AFPM Dave Page <= dpage@pgadmin.org> wrote:


On Wed, 19 Mar 2025 at 11:12, Akshay Joshi <akshay.joshi@e= nterprisedb.com> wrote:
<= div>Hi Dave/Hackers,

I have started working on the= feature #5305.=C2=A0Based on my understanding, the Object Explo= rer should only display nodes or objects where the currently logged-in user= has at least one permission granted in the ACL. In other words, the user m= ust have some level of access to each object displayed.

For example, consider two users: 'postgres' (the default user= ) and 'test'. There are objects, such as a table, where the 'te= st' user does not have any permissions. This table was created by the &= #39;postgres' user, who has revoked all permissions for other users. No= w, if the 'test' user logs into the database server, we need to che= ck whether the logged-in user has any permissions on the object. If not, it= should not be displayed in the Object Explorer.

W= e will have a preference for whether to apply this check or not. There are = following two solutions that can be implemented:=C2=A0
1) Change = the nodes.sql to filter out the nodes based on privileges. It's = challenging, as I tried with aclexplode(relacl), unnest(relacl) in the WHER= E clause, and other different attempts to filter out Table nodes, but seems= we will find some solution for sure).
2) Once nodes are fetched = then filter out the data at the backend.

Any other= solution or suggestion? =C2=A0

This seems like it would be a very large amount of work, for very little g= ain, and would certainly be inconsistent with how we would expect to browse= files and folders for example. I do not think it is worth the effort.

=C2=A0 =C2=A0 OK Thanks, So s= hould we keep this feature request open or close it?=C2=A0

I'd close it.
=C2=A0
<= /div>--
--0000000000009974d00630b1b76e--