Re: Possibility to disable `ALTER SYSTEM`

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, 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>
Subject: Re: Possibility to disable `ALTER SYSTEM`
Date: 2024-03-25 18:26:55
Message-ID: 2523532.1711391215@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> OK, great. The latest patch doesn't specifically talk about backing it
> up with filesystem-level controls, but it does clearly say that this
> feature is not going to stop a determined superuser from bypassing the
> feature, which I think is the appropriate level of detail. We don't
> actually know whether a user has filesystem-level controls available
> on their system that are equal to the task; certainly chmod isn't good
> enough, unless you can prevent the superuser from just running chmod
> again, which you probably can't. An FS-level immutable flag or some
> other kind of OS-level wizardry might well get the job done, but I
> don't think our documentation needs to speculate about that.

True. For postgresql.conf, you can put it outside the data directory
and make it be owned by some other user, and the job is done. It's
harder for postgresql.auto.conf because that always lives in the data
directory which is necessarily postgres-writable, so even if you
did those two things to it the superuser could just rename or
remove it and then write postgresql.auto.conf of his choosing.

I wonder whether this feature should include teaching the server
to ignore postgresql.auto.conf altogether, which would make it
relatively easy to get to a bulletproof configuration.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2024-03-25 18:28:28 Re: Catalog domain not-null constraints
Previous Message Noah Misch 2024-03-25 18:24:43 Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.