On Sat, Jun 25, 2022 at 1:13 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > 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.
Are you claiming that one can manipulate PostgreSQL to do any file writes directly by manipulating pg_proc to call the functions "in a wrong way" ? My impression was that this was largely fixed via disabling the old direct file calling convention, but then again I did not pay much attention at that time :) So your suggestion would be to also include disabling access to at least pg_proc for creating C and internal functions and possibly some other system tables to remove this threat ? Cheers Hannu
