Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes: > Adding a feature which allows a system to run with compromisable > superuser credentials doesn't seem like something the community > usually accepts.
Ashutosh,
I think there’s a misunderstanding. This doesn’t "allow" running with weak superuser creds; it’s a hardening toggle for admins who already recognize the risk and want to remove one of the easiest RCE primitives if superuser does get compromised. Superuser remains fully trusted; the default stays on to preserve behavior and is fully backwards compatible. When an operator explicitly sets it to off and restarts, COPY … PROGRAM is blocked even for superuser, reducing blast radius in misconfigured/legacy environments (e.g., weak/default creds on shared exposed dev/staging stacks).
The intent is defense-in-depth, not to encourage running with compromisable
credentials.
Tom Lane <tgl@sss.pgh.pa.us> writes: > This argument is nonsense, because if you've got superuser you can > just change the GUC's setting again. Not to mention all the *other* > ways that a superuser can break out to the OS level. I don't think > this proposal adds anything except more complication, which is not > a good attribute for security-critical considerations.
Tom,
A quick clarification: enable_copy_program is PGC_POSTMASTER and GUC_DISALLOW_IN_AUTO_FILE. SET/ALTER SYSTEM both error (I added regression tests), and a reload call won’t change it. The only way to flip it is to edit postgresql.conf (or startup params) and restart. So a compromised superuser session cannot just turn it back on.
I agree it doesn’t sandbox superuser or block other breakout paths; the intent is narrowly to remove the most commonly exploited RCE primitive (COPY PROGRAM) when an admin explicitly opts out. Default remains on to preserve behavior.
