Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

Vous n'avez pas encore de compte Developpez.com ? L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Developpez.com

PostgreSQL

Choisissez la catégorie, puis la rubrique :

E.170. Version 7.4.8

[Note]

Date de sortie

2005-05-09

Cette version contient quelques corrections sur la 7.4.7, dont des correctifs sur des failles de sécurité. Pour plus d'informations sur les nouvelles fonctionnalités de la version majeure 7.4, voir Section E.178, « Sortie 7.4 ».

E.170.1. Migration vers la version 7.4.8

Une sauvegarde/restauration n'est pas requise pour ceux utilisant une version 7.4.X. Néanmoins, c'est une façon possible de gérer deux problèmes de sécurité significatifs, qui ont été trouvé dans le contenu initial des catalogues systèmes des versions 7.4.X. Une séquence sauvegarde/initdb/restauration utilisant le initdb de la 7.4.8 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.)

Le problème le moins important est que le module contrib/tsearch2 crée plusieurs fonctions déclarant par erreur renvoyées internal alors qu'elles n'acceptent pas les arguments internal. Ceci casse la sûreté des types pour toutes les fonctions utilisant des arguments internal.

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;

Ensuite, si vous avez installé contrib/tsearch2, faites

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

Si cette commande échoue avec un message comme « function "dex_init(text)" does not exist », alors soit tsearch2 n'est pas installé dans cette base de données, soit vous l'avez déjà mise à jour.

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.170.2. Modifications

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

  • Modification de contrib/tsearch2 pour éviter une utilisation non sécurisée des résultats INTERNAL de la fonction

  • 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.

  • S'assure que les opérations effectuées pendant l'arrêt du serveur sont comptées par le collecteur de statistiques

    Ceci doit avoir résolu les rapports concernant pg_autovacuum, comme quoi il ne lançait pas assez fréquemment VACUUM sur les catalogues systèmes -- il n'a pas été question de suppressions des catalogues causées par la suppression de tables temporaires lors de l'arrêt du serveur.

  • 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

  • Empêche to_char(interval) d'arrêter brutalement le serveur (dump core) pour les formats relatifs au mois

  • Empêche un arrêt brutal sur COALESCE(NULL,NULL)

  • Correction de array_map pour appeler correctement les fonctions PL

  • Correction de la vérification des droits dans ALTER DATABASE RENAME

  • Correction de ALTER LANGUAGE RENAME

  • Make RemoveFromWaitQueue clean up after itself

    Ceci corrige une erreur de gestion du verrour qui pourrait seulement être visible si une transaction a été dégagée de l'attente d'un verrour (typiquement dans le cas d'une requête annulée) et que le détenteur du verrou le relâche dans une fenêtre très petite.

  • Correction d'un problème avec un paramètre non typé apparaissant dans INSERT ... SELECT

  • Correction d'un échec de CLUSTER après ALTER TABLE SET WITHOUT OIDS

Contacter le responsable de la rubrique PostgreSQL

Partenaire : Hébergement Web