On Thu, 4 Dec 2025 at 14:17, Jelte Fennema-Nio <[email protected]> wrote: > > On Thu, 4 Dec 2025 at 05:11, Kirill Reshke <[email protected]> wrote: > > Hi! Superuser can change archive command to arbitrary bash, which is also > > useful for attacker. What should we do in this case? We definitely cannot > > restrict archive command management to localhost, are we? > > I'm curious why you think we cannot restrict archive command > management to localhost? I think we could even completely disallow > changing archive_command with ALTER SYSTEM, by marking it as > GUC_DISALLOW_IN_AUTO_FILE. What user is regularly changing their > archive_command through ALTER SYSTEM in practice, and why couldn't > they change postgresql.conf instead? And if any automation does that, > that could just as easy change postgresql.conf. > > We'd still need to disallow writing postgresql.conf by superuser in > trivial ways, in particular COPY mytable TO > '/abs/path/to/datadir/postgresql.conf'. Maybe even disallow COPY > mytable to 'file', completely by default. > > Yes, this means more is needed than just disallowing COPY PROGRAM. But > I really do think we could spend a little bit of effort to not make > attackers life's as easy as we do today, especially because these > features don't provide any benefit to the majority of our users. And > to make it clear that these blockages are not foolproof, we could > allow people to enable all this functionality again with a GUC like > "allow_trivial_exploits_with_superuser = true" (and add documentation > to make it clear that exploits with superuser access are always > possible, just not the most trivial ones).
I am somehow concerned this should not work. Maybe I am missing something. Let's take one step back > One idea would be to disallow FROM PROGRAM when connecting over the network instead of a Unix socke How this would be protected from connecting to PostgreSQL over the network and then executing dblink, making local (socket) connection? -- Best regards, Kirill Reshke
