Thread: pgsql/src/backend/postmaster postmaster.c

pgsql/src/backend/postmaster postmaster.c

From
Tom Lane
Date:
CVSROOT:    /home/projects/pgsql/cvsroot
Module name:    pgsql
Changes by:    tgl@hub.org    01/02/19 20:34:40

Modified files:
    src/backend/postmaster: postmaster.c

Log message:
    Truncate incoming username and database name to NAMEDATALEN-1 characters
    so that we don't reject overlength names unnecessarily.


Re: pgsql/src/backend/postmaster postmaster.c

From
Peter Eisentraut
Date:
Tom Lane writes:

> Log message:
>     Truncate incoming username and database name to NAMEDATALEN-1 characters
>     so that we don't reject overlength names unnecessarily.

Is this necessarily a good idea?  ISTM that if you send the wrong name,
then it's wrong, period.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Re: pgsql/src/backend/postmaster postmaster.c

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Log message:
>> Truncate incoming username and database name to NAMEDATALEN-1 characters
>> so that we don't reject overlength names unnecessarily.

> Is this necessarily a good idea?  ISTM that if you send the wrong name,
> then it's wrong, period.

No, the problem was inconsistent truncation in different places.
Whilst fixing pg_passwd's clearly-broken truncation to 8 characters,
I experimented with overlength names, and found:

regression=# create user a1234567890123456789012345678901234567890;
NOTICE:  identifier "a1234567890123456789012345678901234567890" will be truncated to "a123456789012345678901234567890"
CREATE USER

which is fine, but then feeding that same username to psql resulted in
failure to connect, because it was effectively truncated to 32 chars not
31, and so didn't match any pg_shadow entries.  If we're going to accept
and truncate overlength identifiers for usernames, then we should do so
consistently.

            regards, tom lane