Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 30, 2024 at 2:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Indeed. I'd go so far as to say that we should reject not only this
>> proposal, but any future ones that intend to prevent superusers from
>> doing things that superusers normally could do (and, indeed, are
>> normally expected to do).
> Also in my opinion, there is a fair amount of nuance here. On the one
> hand, I and others put a lot of work into making it possible to not
> give people superuser and still be able to do a controlled subset of
> the things that a superuser can do.
Sure, and that is a line of thought that we should continue to pursue.
But we already have enough mechanism to let a non-superuser set only
the ALTER SYSTEM stuff she's authorized to. There is no reason to
think that a non-superuser could break through that restriction at
all, let alone easily. So that's an actual security feature, not
security theater. I don't see how the feature proposed here isn't
security theater, or at least close enough to that.
>> Something like contrib/sepgsql would be a better mechanism, perhaps.
> There's nothing wrong with that exactly, but what does it gain us over
> my proposal of a sentinel file?
I was imagining using selinux and/or sepgsql to directly prevent
writing postgresql.auto.conf from the Postgres account. Combine that
with a non-Postgres-owned postgresql.conf (already supported) and you
have something that seems actually bulletproof, rather than a hint.
Admittedly, using that approach requires knowing something about a
non-Postgres security mechanism.
regards, tom lane