PostgreSQL: fermer toutes les connexions sur une base de données

PostgreSQL dispose d’une table d’état très utile appelée pg_stat_activity. Cette table est similaire au « SHOW PROCESSLIST » qu’on retrouve en MySQL, mais a le net avantage d’être requêtable et dispose d’informations plus précises que MySQL.

En voici un extrait:

Dans certains cas, il peut être utile de couper toutes les connexions à une base de données précise (par exemple des connexions dormantes en masse). Voici une simple requête SQL à jouer sur votre PostgreSQL (9.2 et plus) permettant de couper toutes les connexions: Continuer à lire

PostgreSQL: changer le owner de toutes les tables/séquences d’un schéma

Lors d’une restauration de base de données, parfois il se peut que vous ayez besoin de changer le propriétaire d’une table ou d’une séquence pour un autre user, par exemple si vous prenez une base de production pour la mettre sur votre intégration pour vos développeurs (anonymisées, bien sûr 😉 ).

Plutôt que de devoir faire fastidieusement un ALTER TABLE table par table, voici 2 requêtes SQL qui vont vous permettre de générer les SQL pour changer rapidement le owner de toutes les tables et séquences: Continuer à lire

Sécurité: postgresql91

Diverses vulnérabilités ont été découvertes dans PostgreSQL:

  • CVE-2014-0060 Consolider les restrictions de GRANT … WITH ADMIN OPTION (Noah Misch)
    Accorder un rôle sans l’option ADMIN OPTION est supposé empêcher le membre bénéficiaire d’octroyer à d’autres membres l’appartenance au rôle ou de la révoquer, mais cette restriction est aisément contournée en exécutant d’abord la commande SET ROLE. L’impact de sécurité est surtout qu’un membre du rôle peut révoquer l’accès à d’autres, contrairement aux souhaits de celui qui lui a accordé le rôle. L’ajout de membres non validés à un rôle est un moindre souci où un membre de rôle non coopératif pourrait accorder la plupart de ses droits à d’autres de toute façon en créant des vues ou des fonctions SECURITY DEFINER.
  • CVE-2014-0061 Prévenir l’augmentation de droits par des appels manuels à des fonctions de validation de langages procéduraux (PL) (Andres Freund)
    Le rôle principal des fonctions de validation est d’être appelées implicitement durant l’exécution de CREATE FUNCTION, mais ce sont aussi des fonctions SQL normales qu’un utilisateur peut appeler explicitement. Appeler un validateur sur une fonction écrite dans un autre langage pour lequel il n’est pas contrôlé, pourrait être exploité à des fins d’augmentation de droits. La correction implique l’ajout d’un appel à une fonction de vérification de droits dans chaque fonction de validation. Les langages procéduraux additionnels auront aussi besoin de procéder à cette modification pour leurs propres fonctions de validation, si elles existent.
  • CVE-2014-0062 Eviter de multiples résolutions de nom lors l’exécution des commandes DDL sur les tables et index (Robert Haas, Andres Freund)
    Si les résolutions de nom arrivent à des conclusions différentes en raison d’activités simultanées, on peut réaliser une partie des commandes DDL sur une table différente que d’autres parties. Au moins dans le cas de la commande CREATE INDEX, cela peut être utilisé pour faire en sorte que la vérification des permissions porte sur une autre table que la création d’index, permettant une attaque d’augmentation de droits.
  • CVE-2014-0063 Prévenir un dépassement de tampon avec de longues chaînes d’horodatage (Noah Misch)
    La constante MAXDATELEN est trop petite pour la plus grande valeur possible de type intervalle permettant un dépassement de tampon dans interval_out(). Bien que les fonctions d’entrée d’horodatage fassent davantage attention à éviter un dépassement de tampon, la limite est suffisamment courte pour provoquer le rejet d’entrées valides telles que celles contenant un très long nom de fuseau horaire. La bibliothèque ecpg contient ces vulnérabilités avec d’autres qui lui sont propres.
  • CVE-2014-0064 Prévenir un dépassement de tampon dû à un dépassement d’entier dans des calculs de taille (Noah Misch, Heikki Linnakangas)
    Plusieurs fonctions, essentiellement des fonctions de type entrée, calculent les tailles d’allocation sans vérification de dépassement. Si un dépassement survient, un tampon trop petit sera alloué et provoquera un dépassement d’écriture.
  • CVE-2014-0065 Prévenir les dépassements de tampons de taille fixe (Peter Eisentraut, Jozef Mlich)
    Utiliser strlcpy() et les fonctions liées pour fournir une garantie claire que les tampons de taille fixe ne sont pas dépassés. À la différence des points précédents, il n’est pas clair que ces cas représentent vraiment des problèmes réels, étant donné que, dans la plupart des cas, il apparaît qu’il y a des contraintes antérieures sur la taille des chaînes d’entrée. Néanmoins, il semble prudent de rendre silencieux tous les avertissements de Coverity de ce type.
  • CVE-2014-0066 Éviter un plantage si crypt() retourne NULL (Honza Horak, Bruce Momjian)
    Il y a relativement peu de scénarios dans lesquels crypt() pourrait retourner NULL, mais contrib/chkpass peuvent se planter si c’est le cas. Un cas pratique dans lequel cela pourrait être un problème est celui où libc est configuré pour refuser d’exécuter des algorithmes de hachage non-validés (par exemple, mode FIPS).
  • CVE-2014-0067 Documenter les risques de la commande make check dans les instructions de test de régression (Noah Misch, Tom Lane)
    Dans la mesure où le serveur temporaire lancé par make check utilise l’authentification trust, un autre utilisateur sur la même machine pourrait se connecter en tant que superutilisateur de la base de données, et ensuite éventuellement exploiter les privilèges de l’utilisateur du système d’exploitation qui a lancé les tests. Une version à venir introduira probablement des modifications dans les procédures de test pour prévenir ce risque, mais des discussions publiques sont nécessaires auparavant. Aussi pour le moment, il faut simplement prévenir les gens contre l’utilisation de make check quand il y a des utilisateurs non fiables sur la même machine.

Nous vous recommandons fortement de mettre le paquet à jour.

Source

Benchmark comparatif: PostGreSQL 9.1

Suite à une volonté de tester l’arbre de dports de DragonFlyBSD, et voulant voir ce que vallaient les performances de PostGreSQL sur DragonFlyBSD j’ai décidé de monter un rapide benchmark de performances afin de comparer plusieurs systèmes ayant une version de PostGreSQL commune. J’ai choisi pour ces raisons PostGreSQL 9.1.

Lors de mon benchmark sous Linux (Debian), je me suis retrouvé confronté à des statistiques étonnantes en terme de performances, de ce fait, j’ai décidé de voir ce que vallait une Redhat, j’ai donc pris Centos 6.4.

Les tests ont été effectués sur les plateformes suivantes:

  • DragonFlyBSD 3.4.1 (système de fichiers Hammer)
  • FreeBSD 9.1-p3 (système de fichiers UFS2+J)
  • FreeBSD 9.1-p3 (système de fichiers ZFS v28)
  • Debian 7: Wheezy (système de fichiers ext4)
  • Centos 6.4 (système de fichiers ext4)

Continuer à lire

Sécurité (critique): PostgreSQL

Des failles de sécurité critiques ont été découvertes dans PostgreSQL (8.4 à 9.2).

  • CVE-2013-1899
    9.0 et > uniquement: Mitsumasa Kondo and Kyotaro Horiguchi du NTT Open Source Software Center a découvert qu’il est possible, par le biais d’une requête de connexion contenant un nom de base de données commencant par « i », d’endommager ou de détruire des fichiers dans un répertoire de données du serveur. N’importe quel personne pouvant accéder au port pgsql (5432 par défaut) de créer ce type de requête.
  • CVE-2013-1900
    Toutes versions: Les nombres aléatoires générés par les fonctions contrib/pgcrypto peuvent être devinés facilement par un autre utilisateur de la base de données.
  • CVE-2013-1901
    9.0 et supérieures uniquement: Un utilisateur non privilégié peut lancer des commandes qui vont altérer les sauvegardes en cours.

Nous vous recommandons fortement de mettre le paquet à jour