Skip site navigation (1) Skip section navigation (2)

Incautious handling of overlength identifiers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Incautious handling of overlength identifiers
Date: 2016-12-23 19:59:28
Message-ID: 17691.1482523168@sss.pgh.pa.us (view raw or whole thread)
Thread:
Lists: pgsql-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


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2016-12-23 20:03:27
Subject: Re: Parallel Index-only scan
Previous:From: Claudio FreireDate: 2016-12-23 19:54:27
Subject: Re: Vacuum: allow usage of more than 1GB of work mem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group