On Fri, Sep 8, 2023 at 5:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > I don't understand Tom's resistance to this request.
>
> It's false security. If you think you are going to prevent a superuser
> from messing with the system's configuration, you are going to need a
> lot more restrictions than this, and we'll be forever getting security
> reports that "hey, I found another way for a superuser to get filesystem
> access". I think the correct answer to this class of problems is "don't
> give superuser privileges to clients running inside the container".
+1. And to make that happen, the appropriate thing is to identify
*why* they are using superuser today, and focus efforts on finding
ways for them to do that without being superuser.
> > I did not like the mention of COPY PROGRAM, though, and in principle I
> > do not support the idea of treating it the same way as ALTER SYSTEM.
>
> It's one of the easiest ways to modify postgresql.conf from SQL. If you
> don't block that off, the feature is certainly not secure. (But of
> course, there are more ways.)
It's easier to just create a function in an untrusted language. Same
principle. Once you're superuser, you can break through anything.
We need a "allowlist" of things a user can do, rather than a blocklist
of "they can do everything they can possibly think of and a computer
is capable of doing, except for this one specific thing". Blocklisting
individual permissions of a superuser will never be secure.
Now, it might be that you don't care at all about the *security* side
of the feature, and only care about the convenience side. But in that
case, the original suggestion from Tom of using an even trigger seems
like a fine enough solution?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/