> la sécurité d'une base SQLite comparée à son équivalent MySQL est
> nulle par défaut...
C'est tout de même considérer que la sécurité des droits d'accès de ton système est nulle par défaut, ce qui me parait un peut exagérer.
Pour info Mysql aussi stockes sur des fichiers, et la protection des fichiers de Mysql est dépendante des droits d'accès de ces fichiers.
Si tu considère que ces droits d'accès n'offrent aucune protection alors permet moi de te dire que ni mysql ni postgresql n'offrent de protection.
Les serveurs de SGBD n'offrent pas plus de protection, ils offrent une gestion plus fine des droits d'accès (au niveau des partages et des utilisateurs multiples). À la limite si tu as un FS avec des ACL la sécurité sera strictement identique.
> C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http
Si tu en es là il me semble que tu peux arrêter de disserter sur la gestion de la sécu. Le minimum c'est de mettre ta db en dehors de l'arbre exporté par le serveur Web. Les autres SGBD le font bien non ? :)
Ça c'est vraiment des mauvas arguments que tu nous sors
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
Faire dérapper un Apache parce que des scripts PHP moulinent dedans n'importe comment ça m'arrive régulièrement sur la plate-forme de dev (et chez moi et au boulot).
> Patcher les librairies, quand tu prends en charge un tel
> hébergement, c'est pas un gros boulot et ca devrait être dans les
> cordes de tout admin qui se respecte.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon. Par contre tu parlais d'une surveillance plus simple, je suis interloqué que tu trouves que patcher les libs système soit plus simple que les outils de surveillances que doit t'offrir par défaut un SGBD classique.
> Trouver le responsable et envoyer un mail automatique à l'admin
> n'est pas bien difficile à faire... Pas plus que de redémarrer
> apache immédiatement d'ailleurs, de sorte que la coupure soit la
> plus courte possible.
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?
[^] # Re: Aussi pour de petits sites
Posté par Éric (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
> nulle par défaut...
C'est tout de même considérer que la sécurité des droits d'accès de ton système est nulle par défaut, ce qui me parait un peut exagérer.
Pour info Mysql aussi stockes sur des fichiers, et la protection des fichiers de Mysql est dépendante des droits d'accès de ces fichiers.
Si tu considère que ces droits d'accès n'offrent aucune protection alors permet moi de te dire que ni mysql ni postgresql n'offrent de protection.
Les serveurs de SGBD n'offrent pas plus de protection, ils offrent une gestion plus fine des droits d'accès (au niveau des partages et des utilisateurs multiples). À la limite si tu as un FS avec des ACL la sécurité sera strictement identique.
> C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http
Si tu en es là il me semble que tu peux arrêter de disserter sur la gestion de la sécu. Le minimum c'est de mettre ta db en dehors de l'arbre exporté par le serveur Web. Les autres SGBD le font bien non ? :)
Ça c'est vraiment des mauvas arguments que tu nous sors
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
Faire dérapper un Apache parce que des scripts PHP moulinent dedans n'importe comment ça m'arrive régulièrement sur la plate-forme de dev (et chez moi et au boulot).
> Patcher les librairies, quand tu prends en charge un tel
> hébergement, c'est pas un gros boulot et ca devrait être dans les
> cordes de tout admin qui se respecte.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon. Par contre tu parlais d'une surveillance plus simple, je suis interloqué que tu trouves que patcher les libs système soit plus simple que les outils de surveillances que doit t'offrir par défaut un SGBD classique.
> Trouver le responsable et envoyer un mail automatique à l'admin
> n'est pas bien difficile à faire... Pas plus que de redémarrer
> apache immédiatement d'ailleurs, de sorte que la coupure soit la
> plus courte possible.
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?