On Sat, Jun 25, 2022 at 1:13 AM Andres Freund <and...@anarazel.de> wrote:
> > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote: > > Currently the file system access is controlled via being a SUPREUSER > > or having the pg_read_server_files, pg_write_server_files and > > pg_execute_server_program roles. The problem with this approach is > > that it will not stop an attacker who has managed to become the > > PostgreSQL SUPERUSER from breaking out of the server to reading and > > writing files and running programs in the surrounding container, VM or > > OS. > > If a user has superuser rights, they automatically can execute arbitrary > code. It's that simple. Removing roles isn't going to change that. Our code > doesn't protect against C functions mismatching their SQL level > definitions. With that you can do a lot of things. > Yeah, trying to close this hole is a *very* large architectural change. I think a much better use of time is to further reduce the *need* to use superuser to the point that the vast majority of installations can run without having it. For example the addition of the pg_monitor role has made a huge difference to the number of things needing superuser access. As doe the "grantable gucs" in 15, for example. Enumerating what remaining things can be done safely without such access and working on turning that into grantable permissions or roles will be a much safer way to work on the underlying problem (which definitely is a real one), and as a bonus that gives a more granular control over things even *beyond* just the file system access. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
