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