Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>> I'd be much more comfortable if LOCK TABLE caused a message to the log
>> if it is executed on any system table.
>
> Enabled by "set training_wheels = on", perhaps?
>
> This is really pretty silly to be getting worked up about. The command
> in question wouldn't have been allowed at all except to a superuser,
> and there are plenty of ways to catastrophically destroy your database
> when you are superuser; most of which we will never consider blocking
> for the same reasons that Unix systems have never tried to block root
> from doing "rm -rf /". I'd say the real design flaw in Peter's
> referenced application is that they're running it as superuser.
Yeah.. though "lock pg_auth; prepare" looks quite innocent, much more
than say "delete from pg_database" or "rm -rf whatever".
At least to the untrained eye.
I fully agree that that special-casing this particular way to shoot yourself
in the foot is not worth it - but maybe pursuing a more general solution
would be worthwile? Maybe superuser-connections could e.g. ignore
any errors that occur while reading a system table, together with
a big, fat warning, but still allow a logon? That of course depends
on the assumption that basic authentication is possible using just
the information from the flatfiles and pg_hba.conf, which I'm not
sure about.
greetings, Florian Pflug
