Bryn Llewellyn <bryn@yugabyte.com> writes:
> I can't agree with you about risks and probability, though. The general literature of security threats often makes
thepoint that disgruntled employees (current or very recently former) who know the code in question do sometimes wreak
havoc—sometimesjust for sport. The general risk that the unrestricted ability to use "pg_terminate_backend()" to kill
sessionsstarted by one's peers is ordinary denial of service—notwithstanding the possibility for automatic re-connect.
Itstill steals time and resources.
I'm not sure that this argument has much to recommend it. If you
are able to issue arbitrary SQL commands, you can cause effective
denials-of-service in many ways. A couple of random examples:
* launch a query that will eat indefinite amounts of CPU and/or disk.
* "LOCK TABLE some-important-table" and leave for lunch.
* leave a transaction open and go on vacation.
Yeah, you can progressively lock down a system against all of these
sorts of hazards, but it will get progressively less useful for
anyone who wants to do actual work on it.
In the end, the default settings have to represent a compromise
that we think is generally useful. You're welcome to lock your
own installation down more than that, but it doesn't follow that
everybody else should too.
regards, tom lane
