Journal Version de maintenance de postgreSQL

Posté par  .
Étiquettes : aucune
0
15
mai
2005
Tout est dans le titre, ou presque. Vous trouverez plus d'informations à l'adresse suivante :
http://www.postgresql.org/about/news.322(...)
Mais bon, pour étayer un peu mon propos, il s'agit de versions de maintenance qui concernent les versions 8.0.x, 7.4.x, 7.3.x et 7.2.x et corrigent des problèmes de sécurités visiblement très peu probables, ainsi que quelques problèmes d'encodage.
Comme à chaque nouvelle version, la mise à jour est vivement recommandée.
A vos serveurs préférés pour mettre à jour !

  • # PostgreSQL 8.0.3

    Posté par  . Évalué à 3.

    Pour ceux qui s'empresserait de télécharger la dernière version en pensant ainsi se mettre à l'abri des failles de sécurités découvertes récemment, n'oubliez pas de faire un dump/restore de vous bases de données.

    D'après ce que j'ai compris, ils ont changé certains droits par défaut dans les templates, et donc si vous ne faites pas de dump/restore, vous conserverez les droits par défaut de votre version précédente, et donc les failles de sécurités qui vont avec ^^.

    • [^] # Re: PostgreSQL 8.0.3

      Posté par  (site web personnel) . Évalué à 3.

      Bien vu.
      En production on peut éventuellement se passer du Dump/Restore en exécutant les instructions suivantes en superuser:

      UPDATE pg_proc SET proacl = '{=}'
      WHERE pronamespace = 11 AND pronargs = 5
      AND proargtypes[2] = 'cstring'::regtype;

      Pour chacune des bases de données y compris template1 et template0. Pour modifier cette dernière qui est normalement verouillée pour les connections, il faut au préalable la rendre dispo avec:

      UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

      Puis exécuter la requête plus haut et ne pas oublier de verrouiller à nouveau la base ensuite avec un petit VACUUM auparavant:

      VACUUM FREEZE;
      UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

      La seconde vulnérabilité concerne le module tsearch2 et peut elle aussi être corrigée sans Dump/Restore:

      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);

      Voilà, tout ceci pour dire qu'il n'est même pas nécessaire d'interrompre la production pour corriger ces deux petites vulnérabilités.

  • # Private joke :p

    Posté par  (site web personnel) . Évalué à 3.

    http://www.googlefight.com/index.php?lang=en_GB&word1=db2&w(...)

    mais

    http://www.googlefight.com/index.php?lang=en_GB&word1=oracle&am(...)

    d'ou

    http://www.googlefight.com/index.php?lang=en_GB&word1=oracle&am(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.