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@momjian.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 +
