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

At Tue, 24 Jul 2018 14:23:02 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180724052302(dot)GB4736(at)paquier(dot)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(at)paquier(dot)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