Sortie de PostgreSQL 15.3, 14.8, 13.11, 12.15, et 11.20

Publié le 12/05/2023 par Luc Lamarle, Christophe Courtois, Thibaud Walkowiak, David Bidoc, Laura Ricci

Paris, le 12 mai 2023

Le PostgreSQL Global Development Group a publié hier une mise à jour pour toutes les versions supportées de PostgreSQL, soit les versions 15.3, 14.8, 13.11, 12.15, et 11.20. Voici notre traduction.

Cette version corrige deux vulnérabilités de sécurité et plus de 80 bugs rapportés au cours des derniers mois.

Pour la liste complète des changements, veuillez consulter les notes de version.

visuel annonce

Fin de vie de PostgreSQL 11

PostgreSQL 11 cessera de recevoir des correctifs le 9 novembre 2023. Si vous utilisez PostgreSQL 11 dans un environnement de production, nous vous suggérons de planifier une mise à jour vers une version plus récente et supportée de PostgreSQL. Veuillez consulter notre politique de versionnement pour plus d’informations.

Failles de sécurité

  • CVE-2023-2454 : CREATE SCHEMA ... schema_element annule les protections de changement de search_path.

Versions concernées : 11 - 15. L’équipe de sécurité ne teste généralement pas les versions non supportées, mais ce problème est assez ancien. Il permettait à un attaquant ayant les privilèges CREATE au niveau de la base de données d’exécuter du code arbitraire en tant que super-utilisateur. Les propriétaires de bases de données ont ce droit par défaut, et des droits explicites peuvent l’étendre à d’autres utilisateurs.

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

  • CVE-2023-2455 : les politiques de sécurité au niveau des lignes ne tiennent pas compte des changements d’identifiants après l’inlining.

Versions concernées : 11 - 15. L’équipe de sécurité ne teste généralement pas les versions non supportées, mais ce problème est assez ancien.

Alors que CVE-2016-2193 a corrigé la plupart des interactions entre la sécurité des lignes et les changements d’ID utilisateur, il a manqué un scénario impliquant l’inlining de fonction. Cela conduit à l’application de politiques potentiellement incorrectes dans les cas où des politiques spécifiques aux rôles sont utilisées et qu’une requête donnée est planifiée sous un rôle puis exécutée sous d’autres rôles.

Ce scénario peut se produire dans des fonctions avec l’option SECURITY DEFINER, ou lorsqu’une une requête est planifiée par un utilisateur normal, puis réutilisée au travers de plusieurs changements de rôles (SET ROLE). L’application d’une stratégie incorrecte peut permettre à un utilisateur d’effectuer des lectures et des modifications normalement interdites. Ceci n’affecte que les bases de données qui ont utilisé CREATE POLICY pour définir une politique de sécurité des lignes.

Le projet PostgreSQL remercie Wolfgang Walther pour avoir rapporté ce problème.

Correctifs et améliorations

Cette mise à jour corrige plus de 80 bugs rapportés dans les derniers mois. Les problèmes listés ci-dessous affectent PostgreSQL 15. Certains affectent d’autres versions supportées de PostgreSQL.

Sont inclus dans cette version :

  • Plusieurs corrections pour CREATE DATABASE lors de l’utilisation de STRATEGY = WAL_LOG, y compris une corruption potentielle qui pouvait perdre les modifications d’une base template/source.
  • Correction de crash avec CREATE SCHEMA AUTHORIZATION.
  • Plusieurs corrections pour MERGE.
  • Plusieurs corrections pour les triggers dans les tables partitionnées.
  • Interdiction de modifier les types composites stockés dans des index.
  • Garantie que COPY TO depuis une table parent avec une sécurité au niveau des lignes active ne copie pas de lignes des tables enfants.
  • Ajustement de la logique de classification des caractères liés à la recherche de texte afin de détecter correctement si les paramètres régionaux sont à C lorsque la collation par défaut d’une base de données utilise le fournisseur ICU.
  • Ré-autorisation de la notation exponentielle dans les champs d’intervalles ISO-8601.
  • Amélioration des rapports d’erreur pour diverses chaînes JSON invalides.
  • Correction d’une corruption de données due à un vacuum_defer_cleanup_age plus grand que le xid actuel sur 64 bit.
  • Plusieurs corrections pour l’analyseur et le planificateur de requêtes, y compris une meilleure détection des agrégats mal imbriqués.
  • Correction d’un bug dans l’élagage de partitions (partition pruning) avec les conditions booléennes IS NOT TRUE et IS NOT FALSE. Avant cela, les partitions NULL étaient malheureusement éliminées.
  • Correction d’une fuite de mémoire pour les plans d’exécution memoize.
  • Correction d’une fuite mémoire pour les buffers refcount lors d’insertions par lots dans des tables étrangères utilisant des partitions.
  • Rétablissement du support du paramètre vacuum_cost_delay inférieur à la milliseconde.
  • Plusieurs corrections pour les vues et les règles.
  • Éviter des opérations inutiles lors de l’analyse d’un index BRIN à plusieurs colonnes avec plusieurs clés d’analyse.
  • Ignorer les colonnes supprimées et les colonnes générées pendant la réplication logique d’une action UPDATE ou DELETE.
  • Plusieurs corrections concernant le nommage et la disponibilité des événements d’attente.
  • Support des certificats RSA-PSS avec le SCRAM-SHA-256. Cette fonctionnalité nécessite l’utilisation d’OpenSSL 1.1.1 ou d’une version plus récente.
  • Éviter les situations de compétition avec le suivi de l’ID des processus sous Windows.
  • Correction d’une fuite de mémoire à l’intérieur d’une session pour les blocs PL/pgSQL DO utilisant des conversions d’expressions (cast).
  • Renforcement des contrôles de dimension des tableaux issus de PL/Perl et PL/Python lors de la conversion de structures de listes en tableaux SQL multidimensionnels.
  • Correction de pg_dump pour que les tables partitionnées par hachage sur une colonne de type énuméré puissent être restaurées avec succès.
  • Correction de pg_trgm, où une expression régulière insatisfaisante pouvait conduire à un crash lors de l’utilisation d’un index GiST ou GIN.
  • Limitation de l’utilisation de la mémoire de pg_get_wal_records_info() dans pg_walinspect.

Cette version met également à jour les fichiers de données des fuseaux horaires avec la version 2023c de tzdata pour les changements législatifs sur l’heure d’été en Égypte, au Groenland, au Maroc et en Palestine. Quand elles suivent l’heure de Moscou, Europe/Kirov et Europe/Volgograd utilisent désormais les abréviations MSK/MSD au lieu des abréviations numériques, par souci de cohérence avec les autres fuseaux horaires observant l’heure de Moscou. Par ailleurs, America/Yellowknife n’est plus distinct d’America/Edmonton, ce qui affecte certains horodatages antérieurs à 1948 dans cette région.

Mise à jour

Toutes les mises à jour mineures de PostgreSQL sont cumulatives. Comme pour les précédentes, l’appliquer ne nécessite pas de sauvegarder et restaurer les bases de données ou d’utiliser pg_upgrade ; vous pouvez simplement arrêter PostgreSQL et mettre en place les nouveaux exécutables.

Les utilisateurs n’ayant pas appliqué les versions mineures précédentes peuvent avoir besoin de lancer des étapes additionnelles après la mise à jour ; consultez également leurs notes de version.

Liens

DALIBO

DALIBO est le spécialiste français de PostgreSQL®. Nous proposons du support, de la formation et du conseil depuis 2005.