Horton

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

View thread
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: michael@paquier.xyz
Cc: andres@anarazel.de, pgsql-hackers@lists.postgresql.org, robertmhaas@gmail.com, schnjere@amazon.com, pgsql-hackers@postgresql.org, lalbin@scharp.org
Date: 2018-07-24T09:27:16Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve VACUUM and ANALYZE by avoiding early lock queue

  2. Improve TRUNCATE by avoiding early lock queue

  3. Restrict access to reindex of shared catalogs for non-privileged users

  4. Improve behavior of concurrent CLUSTER.

At Tue, 24 Jul 2018 14:23:02 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180724052302.GB4736@paquier.xyz>
> On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote:
> > On July 23, 2018 9:50:10 PM PDT, Michael Paquier <michael@paquier.xyz> wrote:
> >> Oh, yes, that would be bad.  My mind has slipped here.  I have seen
> >> manual VACUUMs on system catalogs for applications using many temp
> >> tables...  So we would want to have only VACUUM FULL being
> >> conditionally
> >> happening?  The question comes then about what to do when a VACUUM FULL
> >> is run without a list of relations because expand_vacuum_rel() is not
> >> actually the only problem.  Would we want to ignore system tables as
> >> well except if allow_system_table_mods is on?  When no relation list is
> >> specified, get_all_vacuum_rels() builds the list of relations which
> >> causes vacuum_rel() to complain on try_relation_open(), so patching
> >> just expand_vacuum_rel() solves only half of the problem for manual
> >> VACUUMs.
> > 
> > I think any such restriction is entirely unacceptable. FULL or not.
> 
> Well, letting any users attempt to take an exclusive lock which
> makes others to be stuck as well is not acceptable either, so
> two possible answers would be to fail
> or skip such relations.  The first concept applies if a relation list is
> given by the user, and the second if no list is given.
> 
> Do you have any thoughts on the matter?

I'm not sure what is the exact problem here. If it is that a
non-privilege user can stuck on VACUUM FULL on the scenario, we
should just give up VACUUM_FULLing on unprivileged relations
*before* trying to take a lock on it. There's no reason for
allowing VACUUM FULL on a relation on that the same user is not
allowed to run VACUUM. I don't think it's a prbolem that
superuser can be involed in the blocking scenario running VACUUM
FULL.

I may be misunderstanding something because (really ?) it's still
extremely hot in Japan, today.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center