Hi,
On 2019-05-10 15:48:49 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-05-10 15:00:18 -0400, Tom Lane wrote:
> >> What exactly is the motivation for changing this now, after 20 years?
>
> > That I've seen enough corruption and other hard to investigate issues
> > related to manual catalog modifications to make me complain. Note that
> > other have complained about this before, too.
>
> So, if the problem is that cowboy DBAs are making ill-advised manual
> changes, how is a SUSET GUC going to stop them from doing that?
> They'll just turn it on and make the same ill-advised change, especially
> after they see us and other people doing exactly that in extensions.
Having to figure out what that GUC is called, looking in the
documentation to do so, seing that there's a large WARNING about it does
reduce risk.
> If you're arguing that the changes were accidental, it seems like the real
> answer to that is "stop using superuser unnecessarily". I don't think
> that adding training wheels to superuser is really a great idea in the
> long run.
Well, we require superuser for a lot of operations with a vastly lower
risk. Like CREATE EXTENSION postgres_fdw etc.. So that's not really a
feasible answer. Nor do we provide a setup, where non-superuser admin
roles exist by default.
> I remember wars back in the last century about whether rm
> should be hacked to disallow "rm -rf /" even to superusers. The eventual
> consensus was "no", and this seems about the same.
Note that rm has prohibited this for a *long* time now (and not just
linux, solaris too). And you've argued for disallowing most DDL against
catalogs...
I don't think it's always obvious to users how dangerous such operations
can be.
Greetings,
Andres Freund