LOXODATA

PostgreSQL 11.4 et autres correctifs

2019-06-25   979 mots, 5 minutes de lecture

Le PostgreSQL Global Development Group a publié une mise à jour de toutes les versions supportées de notre système de base de données, incluant 11.4, 10.9, 9.6.14, 9.5.18, et 9.4.23, ainsi que la deuxième bêta de PostgreSQL 12. Cette publication corrige un problème de sécurité et plus de 25 bogues remontés depuis la dernière mise à jour cumulative en mai.

Cette publication est faite en dehors du planning normal de publication. En effet, la vulnérabilité de sécurité est suffisamment critique pour devoir être corrigée le plus rapidement possible. Les utilisateurs de PostgreSQL 10, PostgreSQL 11 ou PostgreSQL 12 bêta doivent mettre à jour dès que possible.

Les autres utilisateurs doivent planifier la mise à jour au prochain arrêt programmé.

Problème de sécurité

Cette publication clôt une vulnérabilité de sécurité :

  • CVE-2019-10164: dépassement de mémoire de la pile lors du changement d’un mot de passe.

Versions affectées : 10, 11, 12 bêta.

Un utilisateur authentifié peut créer un dépassement de mémoire de la pile en changeant son mot de passe avec une valeur spécifique. En plus de la capacité à « crasher » le serveur PostgreSQL, ceci pourrait être exploité pour exécuter du code arbitraire avec le compte système de PostgreSQL.

De plus, un serveur malicieux pourrait envoyer un message forgé spécifiquement pendant la procédure d’authentification SCRAM et causer le « crash » d’un client libpq ou exécuter du code arbitraire avec le compte système du client.

Ce problème est corrigé en mettant à jour et en redémarrant le serveur PostgreSQL, ainsi que les installations de la bibliothèque libpq. Tous les utilisateurs de PostgreSQL 10, PostgreSQL 11 et 12 bêta sont invités à mettre à jour dès que possible.

Le projet PostgreSQL remercie Alexander Lakhin d’avoir rapporté ce problème.

Corrections de bogues et améliorations

Cette mise à jour corrige aussi plus de 25 bogues depuis la précédente mise à jour cumulative de mai. Certains de ces problèmes ne concernent que la version 11, mais la plupart concernent toutes les versions supportées.

Parmi les problèmes réglés citons :

  • Correction d’erreurs de l’élagage de partition à l’exécution pouvant donner de mauvais résultats pour les requêtes sur des tables partitionnées ;
  • pg_dump recrée maintenant les tables partitionnées en utilisant CREATE TABLE et ALTER TABLE .. ATTACH PARTITION plutôt que l’utilisation de PARTITION OF dans la commande de création ;
  • Améliore la façon dont initdb détermine le fuseau horaire du système à sélectionner lorsqu’il y a une équivalence de nom. De plus, UTC est préféré à UCT ;
  • Corrige un crash possible lors de la copie des définitions des déclencheurs pour une nouvelle partition ;
  • Corrige la défaillance de ALTER TABLE .. ALTER COLUMN TYPE lorsque la table a une contrainte d’exclusion partielle ;
  • Corrige la défaillance de la commande COMMENT pour commenter un domaine ;
  • Plusieurs corrections relatives aux agrégations ;
  • Corrige une génération erronée de plans « merge-append » pouvant amener à des erreurs “could not find pathkey item to sort” ;
  • Corrige la défaillance des dump/restore où les vues contiennent des requêtes avec des noms de jointures dupliquées ;
  • Corrige la conversion de chaine JSON littérale vers une sortie de type JSON dans les fonctions json_to_record() et json_populate_record() ;
  • Corrige une optimisation incorrecte des quantificateurs {1,1} dans les expressions régulières ;
  • Corrige un problème des index B-Tree lors d’une défaillance improbable impliquant des colonnes utilisées par la clause INCLUDE, qui se manifeste avec des erreurs pendant le VACUUM. Si vous êtes impactés par ce problème, vous devrez recréer l’index concerné ;
  • Corrige une condition d’exécution qui sert à vérifier si un segment de mémoire partagé pré-existant est encore utilisé par un postmaster en conflit ;
  • Corrige le processus walreceiver pour éviter un crash ou un interblocage système lors de son arrêt ;
  • Évite un blocage potentiel dans la bibliothèque libpq si l’utilisation du tampon de données en attente de SSL et OpenSSL est un multiple exact de 256 octets ;
  • Corrige l’ordre des commandes GRANT émis par pg_dump et pg_dumpall pour les bases de données et les espaces de tables ;
  • Corrige une erreur de redirection de reindexdb ;
  • S’assure que vacuumdb retourne un statut correct si une erreur survient lors de l’utilisation de tâches parallélisées ;
  • Corrige contrib/auto_explain pour ne pas poser de problème dans les requêtes parallélisées, ce qui entraîne une erreur du type “could not find key N in shm TOC” ;
  • Prise en compte de potentielles modifications de données pour un déclencheur BEFORE ROW UPDATE local dans contrib/postgres_fdw ;
  • Sur Windows, corrige une défaillance quand l’encodage de la base de données est SQL_ASCII et qu’on essaye de tracer une chaine non ASCII.

Mise à jour

Toutes les publications de mises à jour de PostgreSQL sont cumulatives. Comme pour toutes les mises à jour mineures, les utilisateurs ne sont pas obligés d’extraire et de recharger les bases de données ou d’utiliser pg_upgrade pour appliquer cette mise à jour ; il suffit simplement d’arrêter PostgreSQL et de mettre à jour les binaires.

Si un de vos index B-tree utilisant une clause INCLUDE est affecté par le problème signalé ci-dessus, vous devez le reconstruire. Ce problème se manifeste par une erreur se produisant pendant un VACUUM. Pour en savoir plus sur les réindexations :

https://www.postgresql.org/docs/current/sql-reindex.html

Les utilisateurs ayant sauté une ou plusieurs mises à jour peuvent avoir besoin d’étapes additionnelles après la mise à jour. Les notes de publication des versions précédentes fournissent les détails.

PostgreSQL 9.4 ne recevra plus de corrections de bogues à compter du 13 février 2020. Veuillez consulter la politique de version pour plus d’informations.

Planning Bêta

Cette mise à jour est également incluse dans la seconde publication bêta de la version 12. Le projet PostgreSQL publiera d’autres bêtas, autant que nécessaire, suivies par une ou plusieurs publications candidates, jusqu’à la publication de la version finale dans le courant de l’année 2019. Pour plus d’information, veuillez consulter la page bêta Testing.

Liens