Re: Possibility to disable `ALTER SYSTEM` - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id CABUevExhQ5fHjgGvfE7Q905p1RHZDKg0Jxv3J1ypSXCDu-g_OQ@mail.gmail.com
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Mon, Mar 25, 2024 at 7:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.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.

Just to add to that -- if you use chattr +i on it, the superuser in postgres won't be able to rename it -- only the actual root user.

Just chowning it won't help of course, then the rename part works.

--

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Catalog domain not-null constraints
Next
From: "Amonson, Paul D"
Date:
Subject: RE: Popcount optimization using AVX512