
The  following  instructions are important  if  you have upgraded from
PostgreSQL  7.3.9, 7.4.7, 8.0.2, or  any older patch levels within the
7.3,  7.4 or 8.0 versions.  Please  read them carefully,  and -if they
apply to  your situation/setup- follow   them, as the  security  holes
described  here can  not be fixed  in  existing  installations by just
installing the new packages.

There is also a script,  which you can run  as user root to apply  the
needed changes descrbed below to all existing databases:

/usr/share/doc/packages/postgresql/CAN-2005-1409-1410-fix.sh


======================================================================

  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    may  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';

