On Fri, Sep 8, 2023 at 5:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@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/
