| From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Bruce Momjian <bruce(at)momjian(dot)us>, Joel Jacobson <joel(at)compiler(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Magnus Hagander <magnus(dot)hagander(at)redpill-linpro(dot)com>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Possibility to disable `ALTER SYSTEM` |
| Date: | 2024-03-20 13:04:21 |
| Message-ID: | CAKAnmmJ0WAA3bs6P2G8ktVYGamE8D7P+xMkZbVQHE7pW8fjgMQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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.
>
Ugh, please let's not do this. This was bouncing around in my head last
night, and this is really a quite radical change - especially just to
handle the given ask, which is to prevent a specific command from running.
Not implement a brand new security system. There are so many ways this
could go wrong if we start having separate permissions for some of our
files. In addition to backups and other tools that need to write to the
conf files as the postgres user, what about systems that create a new
cluster automatically e.g. Patroni? It will now need elevated privs just to
create the conf files and assign the new ownership to them. Lots of moving
pieces there and ways things could go wrong. So a big -1 from me, as they
say/ :)
Cheers,
Greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2024-03-20 13:07:34 | Re: query_id, pg_stat_activity, extended query protocol |
| Previous Message | Alexander Lakhin | 2024-03-20 13:00:00 | Test 031_recovery_conflict.pl is not immune to autovacuum |