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 1sBUrs-00H1Dt-5n for pgsql-general@arkaria.postgresql.org; Mon, 27 May 2024 07:34:06 +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 1sBUrp-005lEH-QY for pgsql-general@arkaria.postgresql.org; Mon, 27 May 2024 07:34:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with utf8esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sBUro-005lE9-KR for pgsql-general@lists.postgresql.org; Mon, 27 May 2024 07:34:01 +0000 Received: from outbound.visena.net ([46.226.12.34]) by makus.postgresql.org with utf8esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sBUrl-002Bgl-Au for pgsql-general@lists.postgresql.org; Mon, 27 May 2024 07:33:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description; bh=YKyPhDu36teIoWGpnVGIykhIHwbfIhlK4Jg+VQHol6c=; b=n+DyAIf6ReZDAWWf7X6zMZxQSf yw9Md2ZnCYIG2HYVIx1G4PJUA1/v/GGf0NRg3TBwbhYTM4av/+ggFR9FGqDQ2lG2VPntnrC48qaPO RrjC6xxtyCltPkv4my0KNzk3BC+A7amQ4p45o4/jIi3+KtvmLEOqVE259p3fncCymBnU=; Received: from batch01.services.internal.visena.net ([10.3.0.103]) by outbound.visena.net with utf8esmtp (Exim 4.93) (envelope-from ) id 1sBUrf-00AuKt-Pc; Mon, 27 May 2024 09:33:51 +0200 Date: Mon, 27 May 2024 09:33:51 +0200 (CEST) From: Andreas Joseph Krogh To: Tom Lane Cc: pgsql-general@lists.postgresql.org Message-ID: In-Reply-To: <671405.1716570133@sss.pgh.pa.us> References: <671405.1716570133@sss.pgh.pa.us> Subject: Re: prevent users from SELECT-ing from pg_roles/pg_database MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_368828_1892252810.1716795231712" X-Mailer: Visena Mail 3.2.688 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_368828_1892252810.1716795231712 Content-Type: multipart/related; boundary="----=_Part_368829_512658776.1716795231712" ------=_Part_368829_512658776.1716795231712 Content-Type: multipart/alternative; boundary="----=_Part_368830_1544392916.1716795231727" ------=_Part_368830_1544392916.1716795231727 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 fredag 24. mai 2024 kl. 19:02:13, skrev Tom Lane >: Andreas Joseph Krogh writes: > Hi, is there a way to prevent a user/role from SELECT-ing from certain=20 > system-tables? > I'd like the contents of pg_{user,roles,database} to not be visible to al= l=20 > users. As noted, you can in principle revoke the public SELECT grant from those views/catalogs. However, the system is not designed to hide such information, which means you'll have (at least) two kinds of issues to worry about: 1. Queries or tools breaking that you didn't expect to break. It's hardly uncommon for instance for queries on pg_class to join to pg_roles to get the owner names for tables. 2. Information leaks. For example, mapping role OID to role name is trivial with either regrole or pg_get_userbyid(), so it wouldn't take long to scan the plausible range of role OIDs and get all their names, even without SQL access to the underlying catalog. regards, tom lane I tried: REVOKE SELECT ON pg_catalog.pg_database FROM public; But that doesn't prevent a normal user from querying pg_database it seems= =E2=80=A6 -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andreas@visena.com www.visena.com ------=_Part_368830_1544392916.1716795231727 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= P=C3=A5 fredag 24. mai 2024 kl. 19:02:13, skrev Tom Lane <tgl@sss.pgh.pa.us>:
Andreas Joseph Krogh <andreas@visena.com> writes:
> Hi, is = there a way to prevent a user/role from SELECT-ing from certain=C2=A0
&g= t; system-tables?
> I'd like the contents of pg_{user,roles,database}= to not be visible to all=C2=A0
> users.

As noted, you can in = principle revoke the public SELECT grant from
those views/catalogs.=C2= =A0 However, the system is not designed to hide
such information, which = means you'll have (at least) two kinds of
issues to worry about:

= 1. Queries or tools breaking that you didn't expect to break.
It's hardl= y uncommon for instance for queries on pg_class to
join to pg_roles to g= et the owner names for tables.

2. Information leaks.=C2=A0 For examp= le, mapping role OID to role name
is trivial with either regrole or pg_g= et_userbyid(), so it
wouldn't take long to scan the plausible range of r= ole OIDs and
get all their names, even without SQL access to the underly= ing
catalog.

regards, tom lane

=C2=A0

I tried:

REVOKE SELECT ON pg_catalog.pg_database FROM public=
;

But that doesn't prevent a normal u= ser from querying pg_database it seems=E2=80=A6

=C2=A0

--
Andreas Joseph Krogh
CTO / P= artner - Visena AS
Mobile: +47 909 56 963
3D""
=C2=A0
------=_Part_368830_1544392916.1716795231727-- ------=_Part_368829_512658776.1716795231712 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline Content-ID: iVBORw0KGgoAAAANSUhEUgAAAIUAAAAYCAYAAADUIj6hAAAABHNCSVQICAgIfAhkiAAABzBJREFU aEPtmNFxHDcMhmVP3i1VECpvnjzkVIHWFfhcgVcVRKrAUgWRK/C6Al8H3lTgy0PGbzFdQc4VJP/H ADs43q6kROeJNbOYgQACIAgCWJKng4MZ5gxUGXh0U0b+SIuF9G+EWXj2Q15vbrE/NPtk9uub7Gfd t5mBx1NhqSEo8HshjbEUtlO2yIM9tsx5dZP9rPt2MzDZFAqZE4LGcFjdsg3saQaHt7fY70X949On aS+OZidDBkavD33157L4xaw2os+Mp/DAC10l2XhOCeStj0W5ajrJL8WfCi80Xgf9vVlrhg9yRONe /f7xI2vNsIcM7JwU9o6oGyJrLT8JOA1aX9sKP4wl94bAniukEbo/n7YPmuTETzIab4Y9ZWCrKexd 8M58lxPCvvD6aihfvexbEQoPYO8NQRO0JnddGO6FJYaVsBde7cXj7KRk4LsqDxQzCYeGsJNgaXZe +JXkyGgWINq3Gp+bHNILz+wEYs5qH1eJrouNrpDXtk4O6x1IvtD40GWyJYYdkF0jIbYZlN16xygI gl9smbMDsmFdfAKb23xGB8H/mv3tOJfArs1kukk79DEPdQ5u0g1vCvvqKXIW8mZYW+F3Tg4r8HvZ kQCCLydK8EFMQCe5N8RgL9mRG0SqQFuNvdE6beSs0qPDBuCdg0+gvClso8SbTO4ki7mQzQqBrcMH QPwReg2wW8umEe/+L8T/LEzBGF9nXjzZ46s+ITHvhegW8LL39xm6App7KYL/GE+vcYnFbJiP/0aY hdiCnRC7jaj7eiK2ETInC5PRF6LYkSN0+HabF75WuT6syCyI0YkVGGMvUC33AmfZTDUEj8u6IVhu EhRUJ2U2g6UlugyNb03Hl9obHwlxJbcRzcYjO4QPjVfGFTQav4vrmp7cpMp2qbHnBxWJbisbho2Q XI6C1sIHDUFhH4Hij4UbIev66eANeiwbkA+LBsO36zAHzoXU7AhbqLAXEiOYTXcSdO8VS9L4wN8U BIYhBd6oSUgYMijOkecRuTdQa/YiBXhbXFcnCnI2SrfeBG9NydrLYMhGHa5qB9pQIxlzAE6Okjzx JO5afGe6kmhBicWKQNKuTZ5EW+MjQY8v/9rQ0bhJSJyNGUe/JH1t8h1iMbdSPAvxHYin6YmN9YBX QmTYZZNh14vHhhhal5vtcIrJjmvszPRJdExH3MWHvykoBEc9CoCGWJisOLOGoCORs1FvIMbYA8z3 kwM59oemy6LlWrLxFLmWgiQAfEGd8S+NssbK+EhyGLxUkhhiy717waBqHOJYSEacwBejkFNhjJNj v/gANOdQxPfciP/JVBCK2cOIcg3RRJ+CPrLPNVhhN6F38VKMF3XLlIJrjU5C8gMFxvKDvOcPc4rV NjCn7KM0BV+161V8viSCuJZ8SITGJGEh7IUUlxOFMYUH1kJOCN4Wh+I5pqCuK01k40kSNtnKiKIl UfxAgW5sU5JlS05rtt5YFJF1SWoqHv6BRgQcA4/bdb9WRjmMk3jyUMAbIoyJq9e4cVmgzKt9j5gN J/aYDhk+hhjExwaPcz5PObA5Zd9bvz5UzCTZuZDidu5AchpiKSwPR+TV1bCWqBQ9nCjJ5neivC82 Nr4LeS2j1gw5LUqwBuhGQQU5UwHeSslXkwIynz2U2A2yKDgG7OffwLA3TpGRpk0Tzpj3ZEJXi/GR a6GN0e0NtppChePdcAz1FTS+FN8Kpxoiykk+J8fC5tenjbu9kSqpHLu9jBrhUuhNwVGbpyZrzrl0 HPVD8SXj5EOOD/eDC64VjvYBZLuUbIVAfBN1t/C/SU+cAGtdGo+fVnzycUX5wmn6eCKPmWYJG2E/ ppTsuRCbvUD9fwquksG5GqLVKhzDQ3GrEyLKSXhsiK3T5j9EyxffCFOYi2wUlPyFFDQAhehESDjQ GoX0ho0oj8RPou6TxHJdcT0NTcWkO0AnG7+uXsnHqcas/72wvWF+mSf7N/Watp9kTXoluzeS0fB9 9CcZ/hvhSZTfh99pispZOXL9KrGrARkNUMu9ITbScZWs7xOYNt9pwxSZtYDsX/GE3xTkrXgwAsXm fud08FiTeC+m2/o7ppo+PTS/NBK5ARpDG5YHr++DpmVfreYdiX8mnp+DzPEG9WbqJON0JBenZofs sxBA1gj5NXGvfJu/Qh7HwQh/VDUEyUxCit5hH94QfKkEdu+GwK8BX0hvCF+D67xhjmXQCXMwJCZ+ olK0A1EKRCE4snsh42w8Mv/Zhxw9iD7Cjo7CyQC/KyF6oBfShL4PYgG+CHsYKyZxvxZSZBAgjhIz YDz+AbfD37GtbaoSKzgGt+lKfI/GZtay6vG4VXTpPsh+IcQhOk9I7WYeP5AM3HZ9+DaSGIp9HIuu huC4pCGGx+YD2fcc5tfIAA0h/Et4/jX8zz4fWAasIf4UbR9Y6HO4d8jAnd4U0Y8ageuCB+c+H5R3 CHU2mTMwZ+B/y8DfSMBLLOYXVuEAAAAASUVORK5CYII= ------=_Part_368829_512658776.1716795231712-- ------=_Part_368828_1892252810.1716795231712--