Re: Rights Control within DB (which SuperUser cannot access, but user can)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rajesh Mittal <rajjesh(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Rights Control within DB (which SuperUser cannot access, but user can)
Date: 2023-10-05 19:47:27
Message-ID: 2816431.1696535247@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rajesh Mittal <rajjesh(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-05 19:49:37 Re: Pre-proposal: unicode normalized text
Previous Message Rajesh Mittal 2023-10-05 19:38:59 Rights Control within DB (which SuperUser cannot access, but user can)