| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Hannu Krosing <hannuk(at)google(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Pang <robertpang(at)google(dot)com> |
| Subject: | Re: Hardening PostgreSQL via (optional) ban on local file system access |
| Date: | 2022-06-28 23:27:46 |
| Message-ID: | 20220628232746.3cezpzapw2juqnnt@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-06-27 23:36:53 +0200, Hannu Krosing wrote:
> My current thinking is (based on more insights from Andres) that we
> should also have a startup flag to disable superuser altogether to
> avoid bypasses via direct manipulation of pg_proc.
To me that makes no sense whatsoever. You're not going to be able to create
extensions etc anymore.
> Experience shows that 99% of the time one can run PostgreSQL just fine
> without a superuser
IME that's not at all true. It might not be needed interactively, but that's
not all the same as not being needed at all.
IMO this whole thread is largely poking at the wrong side of the issue. A
superuser is a superuser is a superuser. There's reasons superusers exist,
because lots of operations are fundamentally not safe. IMO removing superuser
or making superuser not be a superuser is a fool's errand - time is much
better spent reducing the number of tasks that need superuser.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-06-28 23:29:57 | Re: Transparent column encryption |
| Previous Message | Roberto Mello | 2022-06-28 23:22:34 | doc: BRIN indexes and autosummarize |