Re: Add --{no-,}bypassrls flags to createuser

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com
Cc: michael(at)paquier(dot)xyz, nathandbossart(at)gmail(dot)com, przemyslaw(at)sztoch(dot)pl, david(dot)g(dot)johnston(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, daniel(at)yesql(dot)se, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add --{no-,}bypassrls flags to createuser
Date: 2022-05-26 07:47:46
Message-ID: 20220526.164746.1821317049233715341.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 26 May 2022 14:16:37 +0900, Shinya Kato <Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com> wrote in
> On 2022-05-25 12:47, Michael Paquier wrote:
> > On Wed, May 25, 2022 at 11:07:52AM +0900, Kyotaro Horiguchi wrote:
> >> I reproduced the same failure at my hand and identified the
> >> cause. Windows' version of getopt_long seems to dislike that
> >> non-optional parameters precedes options.
> > Tweaking the list of arguments in some commands kicked by the TAP
> > tests to satisfy our implementation of getopt_long() has been the
> > origin of a couple of portability fixes, like ffd3980.
>
> Thanks! I fixed it.
>
>
> On 2022-05-25 11:07, Kyotaro Horiguchi wrote:
> > At Tue, 24 May 2022 10:09:10 -0700, Nathan Bossart
> > <nathandbossart(at)gmail(dot)com> wrote in
> >> We're still missing some "fancier" string patterns in the tests, but
> >> we
> >> might just be nitpicking at this point.
> > Such "fancier" strings should be properly handled by FmtId() and
> > appendStringLiteralConn. If this is a privilege escalating command,
> > we should have ones but this is not.
>
> Sorry, I didn't quite understand the "fancier" pattern. Is a string
> like this patch correct?

FWIW, the "fancy" here causes me to think about something likely to
cause syntax breakage of the query to be sent.

createuser -a 'user"1' -a 'user"2' 'user"3'
createuser -v "2023-1-1'; DROP TABLE public.x; select '" hoge

BUT, thses should be prevented by the functions enumerated above. So,
I don't think we need them.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2022-05-26 08:17:08 Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~
Previous Message Kyotaro Horiguchi 2022-05-26 07:27:53 Re: fix stats_fetch_consistency value in postgresql.conf.sample