From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Subject: Incautious handling of overlength identifiers
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17690.1482523168.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Dec 2016 14:59:28 -0500
Message-ID: <17691.1482523168@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Pursuant to the report here:
https://www.postgresql.org/message-id/7d0809ee-6f25-c9d6-8e74-5b2967830d49@=
enterprisedb.com
I tried to test all the built-in functions that take "text" (rather
than "name") arguments representing cataloged objects.  I was able
to provoke the same assertion failure in hashname() from these:

regression=3D# select has_column_privilege('postgres','tenk1',repeat('z', 2=
00),repeat('q', 200));
server closed the connection unexpectedly
regression=3D# select has_language_privilege('postgres',repeat('y', 200),re=
peat('z', 200));
server closed the connection unexpectedly
regression=3D# select has_schema_privilege('postgres',repeat('y', 200),repe=
at('z', 200));
server closed the connection unexpectedly
regression=3D# select has_foreign_data_wrapper_privilege('postgres',repeat(=
'y', 200),repeat('z', 200));
server closed the connection unexpectedly
regression=3D# select has_server_privilege('postgres',repeat('y', 200),repe=
at('z', 200));
server closed the connection unexpectedly
regression=3D# select pg_get_serial_sequence('tenk1',repeat('x', 200));
server closed the connection unexpectedly
regression=3D# select pg_get_object_address('table',array[repeat('x', 200)]=
,array[repeat('y', 200)]);
server closed the connection unexpectedly

(Probably many of the code paths in pg_get_object_address can be made to
crash like this, but I stopped after finding one.)

Fortunately, a non-assert build will not crash like this, it'll just
produce a name-not-found failure.

Quite a lot of other functions that didn't crash produced errors
suggesting that they aren't truncating their inputs to NAMEDATALEN
before doing the lookup.  I think this is not expected behavior
either, since direct SQL references to such objects would always
be truncated.

Of the functions that did truncate, there was a remarkable lack
of consistency about whether they produced NOTICEs warning of
the truncation.  I'm not as concerned about that, but I wonder
whether we ought to have a uniform policy about it.

So what to do?  We could run around and fix these individual cases
and call it good, but if we do, I will bet a very fine dinner that
more such errors will sneak in before long.  Seems like we need a
coding convention that discourages just randomly treating a C string
as a valid value of type NAME.  Not sure how to get there though.

BTW, I also notice that parse_ident() doesn't truncate the identifiers
it parses.  ISTM this is a bad thing; isn't more or less the whole
point of that function to convert a string to a name as the Postgres
parser would do?

Comments?

			regards, tom lane


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers