From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Subject: Incautious handling of overlength identifiers
Date: Fri, 23 Dec 2016 14:59:28 -0500
Message-ID: <17691.1482523168@sss.pgh.pa.us> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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=# select has_column_privilege('postgres','tenk1',repeat('z', 200),repeat('q', 200));
server closed the connection unexpectedly
regression=# select has_language_privilege('postgres',repeat('y', 200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_schema_privilege('postgres',repeat('y', 200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_foreign_data_wrapper_privilege('postgres',repeat('y', 200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_server_privilege('postgres',repeat('y', 200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select pg_get_serial_sequence('tenk1',repeat('x', 200));
server closed the connection unexpectedly
regression=# 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us
Subject: Re: Incautious handling of overlength identifiers
In-Reply-To: <17691.1482523168@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox