From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rajesh Mittal <rajjesh@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Rights Control within DB (which SuperUser cannot access, but user can)
In-reply-to: <CAN9AdpveTwZ59aYkRHn27hdwrQOpk6SPHXSOocumqEb9VGnYqg@mail.gmail.com>
References: <CAN9AdpveTwZ59aYkRHn27hdwrQOpk6SPHXSOocumqEb9VGnYqg@mail.gmail.com>
Comments: In-reply-to Rajesh Mittal <rajjesh@gmail.com>
	message dated "Fri, 06 Oct 2023 01:08:59 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2816430.1696535247.1@sss.pgh.pa.us>
Date: Thu, 05 Oct 2023 15:47:27 -0400
Message-ID: <2816431.1696535247@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2816431.1696535247%40sss.pgh.pa.us>
Precedence: bulk

Rajesh Mittal <rajjesh@gmail.com> writes:
> Is there a way, where an authorized user (Creates Table / Inserts Data) in
> a DB, which the SuperUser cannot access the same.
> I understand SuperUser can revoke the access of the user, but he should not
> be able to see the table structure and data inserted in those tables.

You might be able to do something with contrib/sepgsql, if you're
on a selinux-enabled platform.  But TBH the correct solution here
is to not give out superuser to people you don't trust.  There is
no way that you're likely to make an entirely bulletproof setup.
(Consider, just to begin with, how you're going to prevent a rogue
superuser from de-installing sepgsql, or even simply doing
"set role other_user".)

Also keep in mind that "prevent user A from seeing the structure
of user B's tables" is not part of Postgres' threat models at all.
Most system catalogs are world-readable, and you can't change that
without breaking an awful lot of tools.  If you don't like this,
a plausible answer is to give each user their own database.

			regards, tom lane