On Tue, 19 Mar 2024 at 15:52, Tom Lane <t...@sss.pgh.pa.us> wrote: > I like this idea. The "bonus" is not optional though, because > setting the files' ownership/permissions is the only way to be > sure that the prohibition is even a little bit bulletproof.
I don't agree with this. The only "normal" way of modifying postgresql.auto.conf from within postgres is using ALTER SYSTEM, so simply disabling ALTER SYSTEM seems enough to me. > Another question is whether this should be one-size-fits-all for > all the configuration files. I can imagine situations where > you'd like to lock down postgresql[.auto].conf but not pg_hba.conf. > But maybe that can wait for somebody to show up with a use-case. Afaik there's no way to modify pg_hba.conf from within postgres, only read it. (except for COPY TO FILE/PROGRAM etc) So, I don't think we need to worry about this now. On Tue, 19 Mar 2024 at 15:52, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Heikki Linnakangas <hlinn...@iki.fi> writes: > > Perhaps we could make that even better with a GUC though. I propose a > > GUC called 'configuration_managed_externally = true / false". If you set > > it to true, we prevent ALTER SYSTEM and make the error message more > > definitive: > > > postgres=# ALTER SYSTEM SET wal_level TO minimal; > > ERROR: configuration is managed externally > > > As a bonus, if that GUC is set, we could even check at server startup > > that all the configuration files are not writable by the postgres user, > > and print a warning or refuse to start up if they are. > > I like this idea. The "bonus" is not optional though, because > setting the files' ownership/permissions is the only way to be > sure that the prohibition is even a little bit bulletproof. > > One small issue: how do we make that work on Windows? Have recent > versions grown anything that looks like real file permissions? > > Another question is whether this should be one-size-fits-all for > all the configuration files. I can imagine situations where > you'd like to lock down postgresql[.auto].conf but not pg_hba.conf. > But maybe that can wait for somebody to show up with a use-case. > > regards, tom lane
