E.281. Release 7.4.8
Release date: 2005-05-09
This release contains a variety of fixes from 7.4.7, including several security-related issues. For information about new features in the 7.4 major release, see Section E.289 .
E.281.1. Migration to Version 7.4.8
A dump/restore is not required for those running 7.4.X. However, it is one possible way of handling two significant security problems that have been found in the initial contents of 7.4.X system catalogs. A dump/initdb/reload sequence using 7.4.8's initdb will automatically correct these problems.
The larger security problem is that the built-in character set encoding conversion functions can be invoked from SQL commands by unprivileged users, but the functions were not designed for such use and are not secure against malicious choices of arguments. The fix involves changing the declared parameter list of these functions so that they can no longer be invoked from SQL commands. (This does not affect their normal use by the encoding conversion machinery.)
The lesser problem is that the
contrib/tsearch2
module
creates several functions that are misdeclared to return
internal
when they do not accept
internal
arguments.
This breaks type safety for all functions using
internal
arguments.
It is strongly recommended that all installations repair these errors, either by initdb or by following the manual repair procedures given below. The errors at least allow unprivileged database users to crash their server process, and might allow unprivileged users to gain the privileges of a database superuser.
If you wish not to do an initdb, perform the following procedures instead. As the database superuser, do:
BEGIN;
UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;
-- The command should report having updated 90 rows;
-- if not, rollback and investigate instead of committing!
COMMIT;
Next, if you have installed
contrib/tsearch2
, do:
BEGIN; UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype WHERE oid IN ( 'dex_init(text)'::regprocedure, 'snb_en_init(text)'::regprocedure, 'snb_ru_init(text)'::regprocedure, 'spell_init(text)'::regprocedure, 'syn_init(text)'::regprocedure ); -- The command should report having updated 5 rows; -- if not, rollback and investigate instead of committing! COMMIT;
If this command fails with a message like
"
function
"dex_init(text)" does not exist
"
, then either
tsearch2
is not installed in this database, or you already did the update.
The above procedures must be carried out in
each
database
of an installation, including
template1
, and ideally
including
template0
as well. If you do not fix the
template databases then any subsequently created databases will contain
the same errors.
template1
can be fixed in the same way
as any other database, but fixing
template0
requires
additional steps. First, from any database issue:
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
Next connect to
template0
and perform the above repair
procedures. Finally, do:
-- re-freeze template0: VACUUM FREEZE; -- and protect it against future alterations: UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
E.281.2. Changes
-
Change encoding function signature to prevent misuse
-
Change
contrib/tsearch2to avoid unsafe use ofINTERNALfunction results -
Repair ancient race condition that allowed a transaction to be seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner than for other purposes
This is an extremely serious bug since it could lead to apparent data inconsistencies being briefly visible to applications.
-
Repair race condition between relation extension and VACUUM
This could theoretically have caused loss of a page's worth of freshly-inserted data, although the scenario seems of very low probability. There are no known cases of it having caused more than an Assert failure.
-
Fix comparisons of
TIME WITH TIME ZONEvaluesThe comparison code was wrong in the case where the
--enable-integer-datetimesconfiguration switch had been used. NOTE: if you have an index on aTIME WITH TIME ZONEcolumn, it will need to beREINDEXed after installing this update, because the fix corrects the sort order of column values. -
Fix
EXTRACT(EPOCH)forTIME WITH TIME ZONEvalues -
Fix mis-display of negative fractional seconds in
INTERVALvaluesThis error only occurred when the
--enable-integer-datetimesconfiguration switch had been used. -
Ensure operations done during backend shutdown are counted by statistics collector
This is expected to resolve reports of pg_autovacuum not vacuuming the system catalogs often enough - it was not being told about catalog deletions caused by temporary table removal during backend exit.
-
Additional buffer overrun checks in plpgsql (Neil)
-
Fix pg_dump to dump trigger names containing
%correctly (Neil) -
Fix
contrib/pgcryptofor newer OpenSSL builds (Marko Kreen) -
Still more 64-bit fixes for
contrib/intagg -
Prevent incorrect optimization of functions returning
RECORD -
Prevent
to_char(interval)from dumping core for month-related formats -
Prevent crash on
COALESCE(NULL,NULL) -
Fix
array_mapto call PL functions correctly -
Fix permission checking in
ALTER DATABASE RENAME -
Fix
ALTER LANGUAGE RENAME -
Make
RemoveFromWaitQueueclean up after itselfThis fixes a lock management error that would only be visible if a transaction was kicked out of a wait for a lock (typically by query cancel) and then the holder of the lock released it within a very narrow window.
-
Fix problem with untyped parameter appearing in
INSERT ... SELECT -
Fix
CLUSTERfailure afterALTER TABLE SET WITHOUT OIDS