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 1turLX-00Cxtt-9F for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 11:12:27 +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 1turLW-002ESF-0m for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 11:12:26 +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 1turLV-002ERv-LJ for pgadmin-hackers@lists.postgresql.org; Wed, 19 Mar 2025 11:12:25 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1turLT-003gSe-0V for pgadmin-hackers@postgresql.org; Wed, 19 Mar 2025 11:12:24 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-54991d85f99so640783e87.1 for ; Wed, 19 Mar 2025 04:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1742382741; x=1742987541; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=0O/HMoWHh8KyeO+7aLTyVvpN0pz2BMmKZZyjN/8lNJk=; b=glKCbc6mQOcK9QcmLWh0sD64hbNItk7b4q/yV67S21E+Jp5JXvO1lZpfwINmlqoekq X3SihQSpljQ19FerlmuaF65Rqg5pKtVDbWtvEJ2RzIPdrx1uCWguhVIAzWPLKoPR7Bte VB09R6Pg1ezG4+f/Em3vGH8vR658XKqEyS1/9aVt7svPcOp9GK6Q1OgB8nIgLLYV4xmL S6G7ClwhFIz1ykYJRjJT8jyUCwuSl3rXqdO71hYafojj3lRBqesLsHvSCZnxlU3CIYxg bwEWgXe2LVNljdGSGU5COiRrZTDkZZ68rQwgbpyt+Qtn+HtDY8UHQ7ZvH17nTd7gFhbf 4TmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742382741; x=1742987541; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0O/HMoWHh8KyeO+7aLTyVvpN0pz2BMmKZZyjN/8lNJk=; b=bP8wkghtOeAwwteciLMzHlZf4uwkRFR/jQzDk26eAdFHdwZt6tSfZx/XOgqWkjzL3M n13pwSvSzGH6oD4vqmFHXC8+2k3nS7Jt/1oEcQBqji623xU0mhT8hDtvXTfFmjlPgoL2 r+szDDqih5oRLRltcZxJZRBoaR6btlzgpcwcOEy6kSBbuTN/khEopnh4OR4uighSHsS+ pSS2ZK9vl5y1SL5UHUaaSCV/7A7YCz8vbkjdNK5UnSzK1noNAzc2MGNhMkE2ktcZHMaG 8Pr8VQKeUN+EFTIQlW5Ix7TyJj4FK/cMYc6xW7S9LEH2r0P9QCan2avcmMfWkN8rBnDv W6sA== X-Gm-Message-State: AOJu0YwkYtHd61Geqn6RReS0I0z6sp9GyA5UgOzdbxu+AFzVoGOWiX5o mgubDj0Pkele2TOoa0evyXVi3yjRTk8rmymJFMHldwY7xc4HdKV4T8jlRH2fR+gAHRjss9V6UQy 8HsZLhQWqo57IztgzhUds9JFjbD5vfT9BKM4tkEiPnMfMuJM0kA== X-Gm-Gg: ASbGncuqatI1RYgELSl8aGy8/Khh43H+2IbAsGdb14dWWIP/B4dRGV2vvHzpb/sSMIh 2jSizrxqV1rTzfURFDh2RdAXTzcU461ZMZ+dnRaFc+WXPgHhgqLKSL3ExrF0AmaP8W6I4mQhlWP xi5M/2an5gF3O7AvVzfjQUJralC0iBjnrCX459vlmC1jLozgApViCQRqAUxHr+bZTKVwEhsQ== X-Google-Smtp-Source: AGHT+IGVxM+0AVdnUTskV4c4lIjYbW+W1Pt50fbhRk6pes10bXctn5M/xF3XkdM/eXG7K2yQbjNymMDvVVSWE1Bk7FY= X-Received: by 2002:a05:6512:3e10:b0:549:91bd:2d86 with SMTP id 2adb3069b0e04-54a37368d7dmr4287030e87.26.1742382740969; Wed, 19 Mar 2025 04:12:20 -0700 (PDT) MIME-Version: 1.0 From: Akshay Joshi Date: Wed, 19 Mar 2025 16:42:09 +0530 X-Gm-Features: AQ5f1JoAaa7veBzc3DA4H2kaLKClGQeNx4Fa4l-ztzqSVH2Vnx6FXSHlG5g9JhE Message-ID: Subject: Regarding Feature #5305 To: pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000056b2af0630b0185c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000056b2af0630b0185c Content-Type: text/plain; charset="UTF-8" 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 each 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, who has revoked all permissions for other users. Now, if the 'test' user logs into the database server, we need to check whether the logged-in user has any permissions on the object. If not, it should not be displayed in the 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, 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? Akshay Joshi Principal Engineer | pgAdmin Hacker enterprisedb.com * Blog*: https://www.enterprisedb.com/akshay-joshi * GitHub*: https://github.com/akshay-joshi * LinkedIn*: https:// www.linkedin.com/in/akshay-joshi-a9317b14 --00000000000056b2af0630b0185c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave/Hackers,

I have star= ted 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=C2=A0
<= br>

Akshay Jos= hi

Principal Engineer | pgAdmin Hacker

enterprisedb.com

<= /span>

=C2=A0 Blog: https://www.enterprisedb.com/akshay-joshi
= =C2=A0 GitHub: https://github.com/akshay-joshi
=C2=A0 LinkedIn: https://www.linkedin.com/in/akshay-joshi-= a9317b14
--00000000000056b2af0630b0185c--