Re: ProcessStartupPacket(): database_name and user_name truncation

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: ProcessStartupPacket(): database_name and user_name truncation
Date: 2023-06-21 14:22:47
Message-ID: e493eb79-8c8d-1a29-c1c3-730cf7d8d9b9@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 6/21/23 3:43 PM, Tom Lane wrote:
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
>> At Wed, 21 Jun 2023 09:43:50 +0200, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote in
>>> Trying to connect with the 64 bytes name:
>>> $ psql -d ääääääääääääääääääääääääääääääää
>>> psql: error: connection to server on socket "/tmp/.s.PGSQL.55448"
>>> failed: FATAL: database "äääääääääääääääääääääääääääääää" does not
>>> exist
>
>> IMHO, I'm not sure we should allow connections without the exact name
>> being provided. In that sense, I think we might want to consider
>> outright rejecting the estblishment of a connection when the given
>> database name doesn't fit the startup packet, since the database with
>> the exact given name cannot be found.
>
> I think I agree. I don't like the proposed patch at all, because it's
> making completely unsupportable assumptions about what encoding the
> names are given in. Simply failing to match when a name is overlength
> sounds safer.
>

Yeah, that's another and "cleaner" option.

I'll propose a patch to make it failing even for the non multibyte case then (
so that multibyte and non multibyte behaves the same aka failing in case of overlength
name is detected).

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-06-21 14:36:06 Re: pgindent vs. pgperltidy command-line arguments
Previous Message Egor Chindyaskin 2023-06-21 13:45:00 Re: Stack overflow issue