IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #81
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 728
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 728
    Points : 49 104
    Points
    49 104
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    Le fait qu'il y ai plus de CVE déclarés sur PostGresSQL ne veut pas forcément dire qu'il est plus vulnérable que SQL-Server. Les sources PosGresSQL sont libre et donc consultables, il est donc plus facile d'y trouver des failles que sur un code fermé.

    Sauf que si je voulais péter un sql server, j'attaquerais plutôt par RDP, ou dernièrement les failles Exchange et là on inverse complètement la situation.
    Je pose donc deux simples questions :
    1) quel est la proportion d'utilisateur PostGreSQL qui va lire le code pour voir ou se trouve le bug qu'il vient de découvrir ?
    2) pensez vous que 20 ans soit une bonne moyenne pour découvrir un bug gravissime (corruption de données) et 2 ans pour tenter de corriger ce même bug dans PostGreSQL système libre et ouvert, donc selon vous plus facile à maintenir ?

    RÉPONSE 1
    , à mon avis 0,01 %

    RÉPONSE 2
    , voir : https://www.developpez.com/actu/2457...u-FOSDEM-2019/
    Toujours pas corrigé à ce jour !

    Bref, je vous en présenterais d'autres bug PG dont la correction a été pour le moins pittoresque !

    A +

    PS : suite aux prochains épisodes...
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  2. #82
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    14 228
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 14 228
    Points : 32 690
    Points
    32 690
    Par défaut
    En réponse :

    Je répondrais combien pour le code d'SQL-Server ? on ne sait pas, et uniquement des gens de Microsoft. Mais il me semble qu'ils fournissent un accès aux sources en vue d'audit.
    Et avec les produits Microsoft, comme déjà dit, tu as un combo : attaque possible par les CVE d'SQL-Server, mais aussi les autres CVE Exchange, RDS, etc.

    Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les données ne sont pas forcément encore écrite sur le disque, à cause du cache. Et quand on utilise du cache, l'écriture est décalée et il y a un risque, mais on gagne en rapidité car le processus effectuant l'écriture n'attend pas la confirmation de la réelle écriture. C'est la même chose sur Windows, avec comme différence que SQL-Server utilise peut-être ses propres drivers pour écrire sur le disque, plus efficace ou prioritaire que les drivers OS.

    Et des failles non corrigés depuis 20 ans, tu en trouve dans tous les environnements. Et si tu veux jouer ça, veux-tu que l'on parle de badtunnel, faille présente de Windows 95 à Windows 10 (patché)
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  3. #83
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 728
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 728
    Points : 49 104
    Points
    49 104
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par chrtophe Voir le message
    ... Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les données ne sont pas forcément encore écrite sur le disque, à cause du cache. Et quand on utilise du cache, l'écriture est décalée et il y a un risque, mais on gagne en rapidité car le processus effectuant l'écriture n'attend pas la confirmation de la réelle écriture.
    Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
    Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données qui sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

    Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebraker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
    Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

    Quelques éléments à ce sujet :
    https://postgresqlco.nf/doc/fr/param/fsync/
    https://wiki.postgresql.org/wiki/Fsync_Errors

    Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après que des données corrompues se soient propagée dans les bases...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #84
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    14 228
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 14 228
    Points : 32 690
    Points
    32 690
    Par défaut
    Merci pour l'explication sur les LSN.

    Par contre si je prend l'explication :

    Si ce paramètre est activé, le serveur PostgreSQL tente de s'assurer que les mises à jour sont écrites physiquement sur le disque à l'aide d'appels système fsync() ou de méthodes équivalentes (voir wal_sync_method). Cela permet de s'assurer que le cluster de bases de données peut revenir à un état cohérent après une panne matérielle ou du système d'exploitation.
    Bien que désactiver fsync améliore fréquemment les performances, cela peut avoir pour conséquence une corruption des données non récupérables dans le cas d'une perte de courant ou d'un crash du système. Donc, il est seulement conseillé de désactiver fsync si vous pouvez facilement recréer la base de données complète à partir de données externes.
    Je ne comprend pas d’où vient le problème avec PostGres

    As of this PostgreSQL 12 commit, PostgreSQL will now PANIC on fsync() failure.
    c'est donc ça la correction ?

    Si le paramètre de contrôle fsync est activé, et que le fsync échouait la base continuait à fonctionner (donc dans un état potentiellement instable) c'est ça ?

    Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut.
    Là je comprend : défaut de conception.

    extrait de la discussion sur la mauvaise utilisation fsync avec postgresql

    Sinon, pour la petite histoire, Microsoft a fait la même erreur en portant SQL Server sur Linux, car les fichiers étaient ouverts en O_DIRECT seulement. Ils ont vite corrigé ça dès SQL Server 2017 CU8 (https://support.microsoft.com/en-us/...-2017-on-linux).
    Ce qui me fait dire que c'est un peu plus compliqué que ça. Si même Microsoft a fait de cette façon au départ.
    Après il est plus facile d'optimiser les écritures IO directes quand on fait à la fois le SGBD, l'OS, et le filesystem.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  5. #85
    Membre expert

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    2 780
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 780
    Points : 3 952
    Points
    3 952
    Par défaut
    Bonjour,

    Citation Envoyé par SQLpro Voir le message
    Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
    Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

    Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebarker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
    Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

    Quelques éléments à ce sujet :
    https://postgresqlco.nf/doc/fr/param/fsync/
    https://wiki.postgresql.org/wiki/Fsync_Errors

    Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après sue des données corrompues se soient propagée dans les bases...

    A +
    Merci pour ces infos. Je comprend mieux que PostGre soit décrié du coup

  6. #86
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 728
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 728
    Points : 49 104
    Points
    49 104
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
    Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

    Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebarker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
    Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

    Quelques éléments à ce sujet :
    https://postgresqlco.nf/doc/fr/param/fsync/
    https://wiki.postgresql.org/wiki/Fsync_Errors

    Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après que des données corrompues se soient propagée dans les bases...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Réponses: 0
    Dernier message: 09/05/2014, 17h57
  2. Réponses: 5
    Dernier message: 03/02/2010, 23h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo