E.68. Version 7.3.10

E.68.1. Migration vers la version 7.3.10

Une sauvegarde/restauration n'est pas requise pour ceux utilisant une version 7.3.X. Néanmoins, c'est une façon possible de gérer un problème de sécurité significatif, qui a été trouvé dans le contenu initial des catalogues systèmes des versions 7.3.X. Une séquence sauvegarde/initdb/restauration utilisant le initdb de la 7.3.10 corrigera automatiquement ces problèmes.

Le problème de sécurité le plus important est que les fonctions de conversion du codage des ensembles de caractères peuvent être appelées à partir de commandes SQL par des utilisateurs non pribilégiés alors que les fonctions n'ont pas été conçues pour un tel usage et ne sont pas sécurisées contre des choix rusés des arguments. Le correctif implique de modifier la liste déclarée des arguments de ces fonctions pour qu'elles ne soient plus appelées à partir des commandes SQL. (Ceci n'affecte pas leur utilisation normale par la machinerie de conversion du codage.) Il est fortement recommandé que toutes les installations corrigent ces erreurs, soit par un initdb soit en suivant les procédures de réparation données ci-dessous. Les erreurs permettent au moins à des utilisateurs non privilégiés de la base de données d'arrêter brutalement leur processus serveur et pourraient permettre à des utilisateurs non privilégiés de gagner les privilèges d'un superutilisateur.

Si vous souhaitez ne pas lancer d'initdb, exécutez la procédure suivante à la place en tant que superutilisateur de la base de données :

BEGIN;
UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype
WHERE pronamespace = 11 AND pronargs = 5
      AND proargtypes[2] = 'cstring'::regtype;
-- La commande devrait rapporter qu'elle a mis à jour 90 lignes ;
-- si ce n'est pas le cas, annulez (rollback) et investiguez au lieu de valider !
COMMIT;

Les procédures ci-dessus doivent être exécutées pour chaque base de données d'une installation, ceci incluant template1 et devant idéalement inclure aussi template0. Si vous ne corrigez pas les bases de données modèles, alors toute base de données créée par la suite contiendra les mêmes erreurs. template1 peut être corrigé de la même façon que les autres bases de données alors que template0 requiert des étapes supplémentaires. Tout d'abord, à partir de n'importe quel base de données

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

Ensuite, connectez-vous à template0 et effectuez les opérations de réparation. Faites

-- gelez de nouveau template0 :
VACUUM FREEZE;
-- et protégez-contre toute nouvelle modification :
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

E.68.2. Modifications

• Modification de la signature de la fonction de codage pour empêcher toute mauvaise utilisation

• Réparation d'une ancienne condition qui permettait à une transaction d'être vue comme validée pour certains buts (par exemple SELECT FOR UPDATE) légèrement plus tôt que dans les autres buts

  Ceci est un bogue extrêmement sérieux car il pourrait amener à des incohérences apparents des données et visibles brièvement par les applications.

• Réparation d'une condition entre extension de relation et VACUUM

  Théoriquement, ceci pourrait avoir causé des pertes d'une page de données tout juste insérées, bien que la probabilité d'un tel scénario semble extrêmement faible. Il n'existe pas de cas connus où cela a provoqué plus qu'un échec d'Assert.

• Correction des comparaisons des valeurs TIME WITH TIME ZONE

  Le code de comparaison était mauvais dans le cas où le commutateur de configuration --enable-integer-datetimes avait été utilisé. NOTE : si vous avez un index sur une colonne TIME WITH TIME ZONE, il sera nécessaire de le REINDEXer après avoir installé cette mise à jour parce que ce correctif corrige l'ordre de tri des valeurs de colonnes.

• Correction de EXTRACT(EPOCH) pour les valeurs de type TIME WITH TIME ZONE

• Correction d'un mauvais affichage des secondes fractionnelles négatives dans les valeurs INTERVAL

  Cette erreur est seulement survenue quand l'option de configuration --enable-integer-datetimes avait été utilisée.

• Vérification supplémentaires de dépassement de tampon dans plpgsql (Neil)

• Correction de pg_dump pour qu'il sauvegarde correctement les noms des déclencheurs contenant % (Neil)

• Correction de contrib/pgcrypto pour les nouvelles constructions d'OpenSSL (Marko Kreen)

• Encore plus de correctifs 64 bits pour contrib/intagg

• Empêche une optimisation incorrecte des fonctions renvoyant RECORD