Re: PG 12 draft release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 12 draft release notes
Date: 2019-06-12 21:25:37
Message-ID: 20190612212537.if5ybcvqlcqsw74i@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 22, 2019 at 04:50:14PM +0900, Ian Barwick wrote:
> On 5/22/19 4:26 PM, Michael Paquier wrote:
> > On Wed, May 22, 2019 at 09:19:53AM +0900, Ian Barwick wrote:
> > > the last two items are performance improvements not related to authentication;
> > > presumably the VACUUM item would be better off in the "Utility Commands"
> > > section and the TRUNCATE item in "General Performance"?
> >
> > I agree with removing them from authentication, but these are not
> > performance-related items. Instead I think that "Utility commands" is
> > a place where they can live better.
> >
> > I am wondering if we should insist on the DOS attacks on a server, as
> > non-authorized users are basically able to block any tables, and
> > authorization is only a part of it, one of the worst parts
> > actually... Anyway, I think that "This prevents unauthorized locking
> > delays." does not provide enough details. What about reusing the
> > first paragraph of the commits? Here is an idea:
> > "A caller of TRUNCATE/VACUUM/ANALYZE could previously queue for an
> > access exclusive lock on a relation it may not have permission to
> > truncate/vacuum/analyze, potentially interfering with users authorized
> > to work on it. This could prevent users from accessing some relations
> > they have access to, in some cases preventing authentication if a
> > critical catalog relation was blocked."
>
> Ah, if that's the intent behind/use for those changes (I haven't looked at them
> in any detail, was just scanning the release notes) then it certainly needs some
> explanation along those lines.

Since we did not backpatch this fix, I am hesitant to spell out exactly
how to exploit this DOS attack. Yes, people can read it in the email
archives, and commit messages, but I don't see the value in spelling it
out the release notes too.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-06-12 21:36:58 Re: PG 12 draft release notes
Previous Message Bruce Momjian 2019-06-12 21:06:40 Re: PG 12 draft release notes