Vous n'êtes pas identifié(e).
Pages : 1
Merci pour le retour
De mon côté j'ai fait aussi d'autres tests.
A confirmer, mais chez moi ça colle : quand je désactive le module DeepGuard de FSecure je n'ai plus le problème.
J'ai fais une dizaine de démarrages avec, une dizaine sans et visu du log PG juste après.
Des informations supplémentaires ...
Suite au message de Mikael Wallén sur le forum PostgreSQL (https://www.postgresql.org/message-id/1 … sion.local) qui parle d'un éventuel lien avec F-Secure.
Il s'avère effectivement que mes deux postes qui ont le problème utilisent F-Secure.
J'ai donc fait un test sur une VM avec Windows 7 pro 32bits sur lequel PG fonctionne bien : j'ai installé la version de test de F-Secure.
Ça n'a pas loupé : après redémarrage on voit immédiatement le problème dans le log de PG. Ensuite les applis clientes plantent une fois sur 5 environ.
D’après le message de Mikael il se pourrait que Windows Defender soit aussi concerné. Là par contre je ne reproduis pas le problème.
En visualisant par Process Explorer, ASLR n'est pas activé pour postgres.exe
J'utilise le build fourni par EntrepriseDB
Pour info, le même problème signalé en janvier 2014 sur Windows Server 2012 R2 : https://www.postgresql.org/message-id/B … 2F4@maumau
Merci pour ton retour LionelR
De mon côté je n'ai pas le problème sur un poste W7 64 bits (qui est à jour au niveau updates Windows)
Il serait intéressant de connaître la cause du problème et on peut y remédier autrement qu'en redémarrant le service
A suivre, ce poste signalé par rjuju : https://www.postgresql.org/message-id/f … gresql.org
Bonjour
Comment connaître le status de l'ASLR sur Windows 7 ?
La seule info que j'ai trouvée c'est comment le désactiver (https://ulbright.com/2013/11/06/disable … windows-7/)
Cette clé n'est pas présente chez moi, ça veut dire que l'ASLR est activé ?
Bonjour
LionelR, tu as eu ce problème ce problème sur un poste 32 bits ou 64 bits ?
De mon côté c'est arrivé sur deux postes en 32 bits (Win 7 pro aussi) et je voudrais savoir si ça touche aussi les 64 bits
Merci de ton retour
Merci pour ta réponse
J'ai fait des recherches il y a une semaine sur le sujet et il n'y avait encore rien sur les forums.
C'est déjà une piste en tout cas, merci.
C'est vrai que PG fonctionnait très bien depuis plus d'un an sur ce poste.
Dans mon cas la réinstallation n'a rien donnée, j'ai eu le même problème avec la version 9.5.5 nouvellement installée
Par contre ce matin j'ai installé pour test la 9.6 sur ce poste et pour l'instant pas de problème remonté.
Pour ceux qui ont le problème : chez moi, le problème est présent uniquement sur un Windows 7 Pro 32 bits. Sur mon poste, en Windows 10 Pro 64bits, je n'ai pas eu de soucis
Bonjour
Je rencontre actuellement un problème avec PostgreSQL sur un poste Windows 7 32 bits
La version installée de PostgreSQL est la 9.5
Le message retourné (à la connexion) par le logiciel client est :
"n'a pas pu lancer le nouveau processus fils pour la connexion : No error"
Dans le log de PostgreSQL j'ai ces deux lignes qui sont ajoutées de nombreuses fois :
2016-11-05 07:59:42 CET LOG: could not reserve shared memory region (addr=01AA0000) for child 00000538: error code 487
2016-11-05 07:59:42 CET LOG: n'a pas pu exécuter le processus autovacuum worker : No error
Je précise que si je copie le répertoire \data sur un autre poste (qui est en 64 bits avec PostgresQL en 32 bits) je peux accéder aux données.
La base n'est donc pas endommagée
Sur le poste incriminé, j'ai d'abord eu le problème avec PostgreSQL 9.3
Je l'ai complètement désinstallé, j'ai supprimé le répertoire des données, j'ai installé PG 9.5.5 et restauré une sauvegarde.
Et le problème est survenu à nouveau assez rapidement.
De temps en temps ça fonctionne et mon application démarre
Je pense à un problème de RAM vu qu'il s'agit d'une version 32 bits de l'OS mais j'aimerais m'assurer que ce n'est pas autre chose
Avez-vous eu ce type d'erreur et pouvez-vous m'en dire plus à son sujet ?
Bonjour
.
Un petit retour pour ceux que ça pourrait intéresser. J'ai eu la réponse de le société EntrepriseDB par l'intermédiaire de son distributeur français (Think) :
.
"The answer to this question is: Yes. They may download our PostgreSQL GUI installer and bundle / re-distribute it freely. EDB distributes PostgreSQL under the PostgreSQL License, which prevents EDB from not allowing this"
Bonjour
Savez-vous si l'installeur graphique Windows fourni par EntrepriseDB est redistribuable ?
J'ai du mal à trouver des informations de licence sur leur site
Je suis d'accord avec toi dverite il vaut mieux certainement protéger un peu plus même si c'est contournable
Je n'ai jamais fait de recompilation et j'avoue que ça me fait un peu peur
Je vais quand même me renseigner sur le sujet
Les gens qui vont utiliser l'application ne sont ni des admin, ni des développeurs, mais on ne sait jamais ...
Merci gleu et ruizsebastien pour vos remarques
.
De toute façon c'est clair qu'en mode admin je ne peux pas protéger grand chose
Mais il faut relativiser, je suis plutôt en mode parano mais ça n'arrivera surement jamais qu'un client connaisse la manip pour passer en mode trust ou même qu'il tente de le faire
.
Au pire si ça arrive j’essaierai de le tracer.
Et concernant les données sensibles elles seront cryptées de toute façon
.
@ruizsebastien si c'est possible d'installer PostgreSQL sur un "vrai" serveur je le ferai mais malheureusement dans la plupart des cas on sera juste fournisseur de l'application et le client nous dira juste où l'installer (on fait les install à distance)
.
Merci à tous de vos lumières, je reviendrai certainement vers vous pour d'autres questions
Merci pour la piste dverite
Je vais étudier la question et voir si ça vaut le coup par rapport à l'éventuel risque d'une modif du .conf
Je n'ai jamais fait de recompilation en effet
Alors ça veut dire qu'on ne pourra jamais sécuriser une base PostgreSQL dans ce genre de configuration.
ça me refroidit un peu sur le fait d'utiliser PostgreSQL qui pourtant me réjouissait
.
On a déjà passé beaucoup de temps sur le modèle de données, les benchs, la reprise de données (Access), les maquettes ... changer maintenant ferait une sacré rallonge à notre planning
Et puis changer pour quelle autre base ?
.
Je vais quand même mémoriser l'horodatage du fichier pg_hba.conf pour au moins être tenu au courant si il a été modifié
.
Merci de tes réponses
Merci de ta réponse rjuju
.
Je ne cherche pas à empêcher ça, je ne pourrais pas car je n'aurai pas le droit de faire ce genre de manip chez le client.
De plus le client sera en général administrateur de sa machine
La question n'est là. La question c'est plutôt : existe t'il un moyen pendant l'installation de spécifier que le mode (md5 en l'occurence) ne pourra jamais être modifié, et ce, même si le fichier pg_hba.conf est modifié (car je ne peux pas empêcher sa modification) ?
.
En gros un autre fonctionnement que par pg_hba.conf
Bonjour à tous
N'ayant pas eu de succès sur un autre forum j'ai trouvé celui-ci qui me semble plus approprié
.
Voici ma question :
.
Je suis en phase de test de PostgreSQL pour un nouveau projet
L'objectif est de diffuser notre application avec PostgreSQL dans des points de vente. L'installation sera fera certainement en batch à partir des binaires
Dans la majorité des cas il y aura quelques postes en réseau et une volumétrie pas énorme
Bref au niveau des performances je ne me fais pas trop de soucis, les tests sont concluants
.
Ce qui me dérange c'est l'aspect sécurité, vous allez peut être me dire que je me trompe (j'espère)
Dans ce genre d'installation, il y aura rarement un serveur mais c'est un poste du magasin qui fera office de serveur
.
Donc mon souci est au niveau de la sécurité
Comment protéger l'accès aux données ?
.
D'après mes premiers tests il suffit de remplacer "md5" par "trust" dans le pg_hba.conf et il n'y a plus aucune sécurité, on peut entrer sans mot de passe avec n'importe quel compte !
.
Je sais bien que les clients ne vont pas faire ce genre de manip mais c'est possible, c'est ça qui me gêne beaucoup
Et puis dans tous les cas je dois interdire la modification de données en dehors de mon application
.
Existe-t-il un moyen de sécuriser une installation PostgreSQL "locale" ?
Pages : 1
