PostgreSQL : permission non accordée sur les fichiers

Bonjour,

J'utilise PostgreSQL 14 sur Ubuntu 21.10.

Je souhaiterais lire des instructions à partir d'un fichier, mais psql n'a pas les droits :

user@ordi:~$ sudo -i -u postgres psql
[sudo] Mot de passe de user : 
psql (14.1 (Ubuntu 14.1-1.pgdg21.10+1))
Saisissez « help » pour l'aide.

postgres=# \i /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql
/home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql : Permission non accordée

J'ai tenté d'ouvrir les droits sur le dossier, avec une méthode ou une autre, mais sans succès :

$ chmod -R 777 leDossierDeTravail

Je ne rencontrais pas ce problème de droits sur une configuration antérieure, avez-vous une idée ?

Bonjour,

Si tu mets un chemin devant le nom du fichier .pgsql, il faut aussi que tous les répertoires apparaissant dans ce chemin soient accessibles à l'utilisateur psql.

Amicalement,

Et l'eau,
Que donne la commande ?

user@ordi:~$ ls -lah /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql

si tu fais ceci (tu te fais passer pour l'utilisateur postgres):

user@ordi:~$ sudo su postgres
[sudo] Mot de passe de root :
....
postgres@ordi:/home/user$

Est ce que ça fonctionne ?
Est ce qu'en faisant un chown, ça résout ton problème ?

Quelles sont les droits sur le fichier pg_hba.conf ? Je veux dire, quel est son contenu ?

ps : geek culture -> https://www.explainxkcd.com/wiki/images/b/b1/sandwich.png
Modifié par niuxe (04 Feb 2022 - 21:18)

Ok, je suis de retour à la maison. Je vais regarder tout ça maintenant et je vous tiens au courant de suite...

niuxe a écrit :
(1) Que donne la commande ?

-rwxrwxrwx 1 user user 21K févr.  4 09:07 /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql

niuxe a écrit :
(2) Est ce que ça fonctionne ?

Oui. j'ai ça :

postgres@ordi:/home/user$

niuxe a écrit :
(3) Est ce qu'en faisant un chown, ça résout ton problème ?

J'ai déjà vu passer cette commande sur un forum hier, je ne sais pas m'en servir, je vais regarder de plus près ce mode groupal.

niuxe a écrit :
Quelles sont les droits sur le fichier pg_hba.conf ? Je veux dire, quel est son contenu ?

Je te fais grâce des commentaires d'introduction :

# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

Modifié par Olivier C (04 Feb 2022 - 21:52)

Olivier C a écrit :

-rwxrwxrwx 1 user user 21K févr.  4 09:07 /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql

Ce qui est bizarre, il y a tous les droits sur le fichier. Essaie de faire ça :

user@ordi:~:$ sudo chown postgres:postgres /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql

Ensuite tu retentes dans postgres, ta manip. C'est quoi ce fichier ?

edit1 : en te relisant un peu mieux, ton fichier permet d'insérer un schema. Si c'est le cas, comment a t'il été exporté ? via pg_dump ?

As tu essayé de faire ceci ?

user@ordi:~$psql -u postgres -d madatabase < /home/user/Documents/GitHub/leDossierDeTravail/database/logicalDataModel.pgsql

edit2: J'utilise une SLED. Sur cette distribution, c'est le nom et le groupe pour postgres. Logiquement sur une Debian/Debian like, tu devrais avoir la même chose. Pour t'en assurer, vérifie en faisant un ls sur le pg_hba.conf

Olivier C a écrit :

Oui. j'ai ça :

postgres@ordi:/home/user$

Là où je voulais en venir c'était de te faire passer pour postgres dès le départ et ensuite te connecter dans pgsql.

user@ordi:~$sudo su postgres
...
postgres@ordi:~$psql
postgres=# \i /home/... 

Mais je pense que c'est peine perdue puisque dans postgrsql, tu es sous cet user (postgres = super admin dans cette sgbdr)

Olivier C a écrit :

J'ai déjà vu passer cette commande sur un forum hier, je ne sais pas m'en servir, je vais regarder de plus près ce mode groupal.

rtfm....

user@ordi:~$man chown

Modifié par niuxe (05 Feb 2022 - 00:17)

Ah oui, merci pour la commande man, je ne manipule pas assez la console et parfois j'oublie ce genre de chose. Au cas où, j'ai quand même tenté la commande `sudo chown postgres:postgres...`, mais elle n'a rien donnée.

Je n'ai pas fait ceci : `psql -u postgres -d madatabase < etc...` (les balises inline ça manque vraiment sur alsa) car le fichier doit justement se lancer directement à partir de postgres.

logicalDataModel.pgsql est un fichier de configuration qui crée un nouvel utilisateur et une base de donnée liée à cet utilisateur, ainsi que les tables de cette base, avec un peu de remplissage de ces tables à destination de test. Pour donner une idée, une ancienne version de ce fichier est ici, la nouvelle version n'est pas encore publique (je n'est rien de secret mais c'est surtout pour éviter les erreurs de sécurité avant publication définitive). Quoi qu'il en soit ça "marchait" avant, et plus rien depuis que j'ai mis à jour Ubuntu. Pourtant, sur l'ancienne configuration (19.10) je n'avais rien fait de particulier...

Bon, je vais devoir laisser cette question en suspens ce jour par manque de temps, merci pour vos interventions. Si je trouve la soluce - et ce n'est pas gagné vu mon niveau de linux - je vous le ferais savoir.

Olivier C a écrit :
Ah oui, merci pour la commande man, je ne manipule pas assez la console et parfois j'oublie ce genre de chose. Au cas où, j'ai quand même tenté la commande `sudo chown postgres:postgres...`, mais elle n'a rien donnée.

On est d'accord qu'ensuite, tu t'es connecté à postgr et refait la manip d'importation ? Je me doute que oui.

Olivier C a écrit :

Je n'ai pas fait ceci : `psql -u postgres -d madatabase &lt; etc...` (les balises inline ça manque vraiment sur alsa) car le fichier doit justement se lancer directement à partir de postgres.

Cette manip te permet de faire un import depuis un tty. Tu as un utilitaire intéressant comme pg_restore . Vois de ce côté-là.

Ce que tu peux faire aussi, faire un tail -f du syslog et postgresql-xx-xx-xx_xxxxx.log lors de ton import. Chez moi, les log de postgrs sont à cet endroit :
/var/lib/pgsql/data/log . Sur une Debian ou Debian like, il se peut qu'ils soient ailleurs (/var/log/....).

Olivier C a écrit :

Quoi qu'il en soit ça "marchait" avant, et plus rien depuis que j'ai mis à jour Ubuntu. Pourtant, sur l'ancienne configuration (19.10) je n'avais rien fait de particulier...

dist-upgrade n'est jamais à prendre à la légère. Ensuite, Ubuntu ouais un gros bof (surtout si tu utilises une version rolling release) ! Tourne toi vers Debian Au début, la courbe d'apprentissage sera déroutante comparé à Ubuntu/Mint (le wiki + debian-facile.org t'aideront beaucoup). Mais finalement, tu verras que c'est tellement mieux (y'a pas photo !). Avec ta Debian, tu peux récupérer quelques dépôts intéressants comme les non free (installation du wifi par exemple).
Modifié par niuxe (05 Feb 2022 - 16:47)

Oui, effectivement j'ai toujours ces problèmes de droits malgré les manips. Je suis sûr que ce n'est pas une erreur de configuration de ma part sur mon Ubuntu car j'ai refais exprès une installation propre et j'ai le même problème.

Bien sûr je pourrais changer de distribution, mais bon, Ubuntu c'est mon bureau par défaut et il me convient parfaitement, malgré des choix que l'on peu discuter (comme les snaps). Certainement qu'il faudrait que je me mette à des stacks passe partout qui me permettrait peut-être de régler ce type de problème (comme Docker, pour lesquelles j'ai un intérêt, comme j'ai pu l'exprimer sur l'article Alsa dédié). Mais j'éprouve depuis quelques temps la framework fatigue, la stack fatigue ; l'empilement toujours plus important des technos me fatigue. Au final je reste un amateur et j'ai peu de temps pour coder en ce moment, même si cela reste une passion. J'aimerais passer plus de temps à coder et moins à configurer...

A tout hasard, je vais m'inscrire sur le forum postgreSQL français pour poser ma question. Si je trouve une solution je vous ferais un retour. Merci encore à vous deux.
Modifié par Olivier C (08 Feb 2022 - 09:57)

parsimonhi a écrit :
Si tu mets un chemin devant le nom du fichier .pgsql, il faut aussi que tous les répertoires apparaissant dans ce chemin soient accessibles à l'utilisateur psql.

Je ne t'avais pas répondu Parsimonhi, excuse-moi.

Je ne pense pas que les droits sur Linux fonctionnent comme cela. Cela voudrait dire qu'il faudrait donner les permissions à tout le répertoire racine pour commencer, ce qui n'est pas possible. Pour la petite histoire, je l'ai fais une fois par erreur de manip' et je ne pouvais plus accéder à la commande `sudo` : celle-ci est liées à un fichier racine dont les droits doivent être restreint.

Bref, à partir du moment où tu donne les droits sur un fichier, le chemin pour y accéder est forcément ouvert lui aussi. Ou alors quelque-chose m'échappe.
Modifié par Olivier C (08 Feb 2022 - 10:04)

Olivier C,

J'ai pris ton fichier et j'ai importé tes données dans mon env. ça fonctionne !

Olivier C a écrit :
Bien sûr je pourrais changer de distribution, mais bon, Ubuntu c'est mon bureau par défaut et il me convient parfaitement,

Canonical commence, mais ne finit jamais ! Il n'y a pas que les snap qui sont discutables. Les versions intermédiaires aux LTS sont vraiment pourries (paye ta pléthore de bugs en tous genres).
Pour info, ça va faire plus de 7-8 ans que j'ai largué Ubuntu. Je ne m'en porte pas plus mal. Dans le libre, tu fais ce que tu veux ! Il y a quelques mois, j'ai fait une élévation de version de ma distribution et pas de souci à l'horizon. Je peux t'assurer qu'il y a beaucoup de choses installées (mariaDB, postgres, mongodb, php, apache, python3, docker, etc., etc.). Pourquoi 2 SGBDR sur ma machine ? ça dépend des projets sur lequel je travaille. D'une manière générale, je migre définitivement sur postgres.

Pour ton histoire de bureau, bah c'est du gnome à la sauce Canonical parce que Unity est passé aux oubliettes... Si tu désires du *.deb, je te conseille vivement Debian. Debian en tant que workstation, c'est de la balle ! Après, il faut comprendre qu'il y aura forcément une petite courbe d'apprentissage pour dompter la bête. Le jeu en vaut la chandelle !

Pour finir, les bureaux dans GNU/Linux, c'est très subjectif. Il faut plutôt se concentrer sur la qualité de la distribution que sur le bureau . Pour une machine, j'ai installé une Debian avec LXDE. Le contexte est que je dois absolument avoir un bureau léger. Quand tu installes LXDE sur Debian, ça pique les yeux la première fois. Mais tu as la fiabilité ! Il est à noter qu'LXDE est moins bien (fonctionnellement parlant) que KDE ou Gnome.
Modifié par niuxe (08 Feb 2022 - 13:46)

niuxe a écrit :
Olivier C, J'ai pris ton fichier et j'ai importé tes données dans mon env. ça fonctionne !

Wahou ! Là bravo !

niuxe a écrit :
Canonical commence, mais ne finit jamais ! Il n'y a pas que les snap qui sont discutables. Les versions intermédiaires aux LTS sont vraiment pourries (paye ta pléthore de bugs en tous genres).

Oui, c'est vrai, je me souviens de nombreux bugs avec la version 19.10.

niuxe a écrit :
D'une manière générale, je migre définitivement sur postgres.

Moi je tente, mais bon, maintenant, avec deux enfants en bas âge et une maison à retaper ça fait 3 ans que je tente sans aboutir mon projet en cours...

niuxe a écrit :
Pour finir, les bureaux dans GNU/Linux, c'est très subjectif. Il faut plutôt se concentrer sur la qualité de la distribution que sur le bureau.

C'est vrai, et en même temps, j'ai testé pas mal de distros, et j'ai vu que le comportement n'est pas toujours optimisé d'une plate forme à une autre. Par exemple j'aimais beaucoup Fedora (34 et 35) pour le côté épuré de Gnome (dont je suis un des rares fans francophone apparemment). Mais j'avais beaucoup de logiciel qui, s'ils semblaient être disponibles sur un même pied d'égalité qu'avec Ubuntu étaient largement moins optimisés et j'avais beaucoup de plantage (et évidement il faut ajouter tous les codecs propriétaires, même pour lire un .mp4, parce qu'on est des librites, hein).
Peut-être devrait-je installer deux environnements, dont un pour le dev', soit en VM (argh), soit avec Docker/Debian (mais je ne sait pas pour ce dernier cas si cela changerait quelque-chose).

Aller tu m'as convaincu : je vais déjà faire un test en VM...

Édit : c'est bon j'y suis mais je suis déjà obligé remettre ça pour ce soir. Ouf : je suis un fan de Gnome, mais retour à la version 3.38 ça fait mal. Si je m'y mets définitivement ça restera que pour le développement.
Modifié par Olivier C (08 Feb 2022 - 16:24)

Olivier C a écrit :

Wahou ! Là bravo !

Je n'ai fait qu'un simple import (pas de bidouillage particulier).
1. Je me suis connecté afin de savoir si le service était ouvert.
2. j'ai quitté pour revenir sur le shell
3. j'ai lancé la cmd

Olivier C a écrit :

Oui, c'est vrai, je me souviens de nombreux bugs avec la version 19.10.

la 17.10 que je n'ai pas connu a été un désastre ! Certains ordis sont inutilisables. Suite à une mise à jour foireuse de Canonical, les ports usb fusillés. Quand l'ordi n'a pas de lecteur/graveur CD, bonne chance !

Olivier C a écrit :

Moi je tente, mais bon, maintenant, avec deux enfants en bas âge et une maison à retaper ça fait 3 ans que je tente sans aboutir mon projet en cours...

Je sais, tu me l'avais plus ou moins dit

Olivier C a écrit :

C'est vrai, et en même temps, j'ai testé pas mal de distros, et j'ai vu que le comportement n'est pas toujours optimisé d'une plate forme à une autre. Par exemple j'aimais beaucoup Fedora (34 et 35) pour le côté épuré de Gnome (dont je suis un des rares fans francophone apparemment). Mais j'avais beaucoup de logiciel qui, s'ils semblaient être disponibles sur un même pied d'égalité qu'avec Ubuntu étaient largement moins optimisés et j'avais beaucoup de plantage (et évidement il faut ajouter tous les codecs propriétaires, même pour lire un .mp4, parce qu'on est des librites, hein).
Peut-être devrait-je installer deux environnements, dont un pour le dev', soit en VM (argh), soit avec Docker/Debian (mais je ne sait pas pour ce dernier cas si cela changerait quelque-chose).

Pour utiliser Docker, il faut avoir de bonnes connaissances de GNU/Linux. Surtout si tu dois faire un dockerfile. Aussi, il faut bien comprendre la mécanique. Rodolphe a su via ses 2 papiers "banaliser" le sujet. Bravo à lui. Docker est un sujet assez complexe quand même (surtout si tu comptes envoyer ça en prod (en ligne)). Docker est un excellent outil que je connais depuis 5 ans et que j'utilise régulièrement.

En ce qui concerne Fedora, tu fais encore la confusion entre le bureau et la distribution. Quitte à être sur des paquets *.rpm (originels), je me tournerai sur alma linux ou oracle linux. CentOS faut désormais oublier. Il y a eu énorméments de mouvements à popos de CentOS. Avant leur annonce, c'était une excellente idée de l'utiliser.

Tu veux un Gnome à la sauce Fedora ? Debian ou OpenSuse/SLED/SLES ! Bien que Debian supporte bien les bureaux, gnome est devenu le bureau par défaut. Certes, tu n'auras pas la dernière version. Mais tu auras la version stable ! Red Hat est l'un des acteurs majeur de GNU/Linux. Fedora repousse constament les limites. On leur doit beaucoup. Le souci, Fédora est une pseudo rolling release. Donc, il me semble que ce ne soit pas si fiable. Je veux me tourner de ce côté là, je regarderai la redhat linux enterprise (elle va devenir ou elle est gratuite) ou Alma ou Oracle Linux.

Tout à l'heure, tu parlais des paquets snap. Fedora a inventé (entre autres) les flatpack. Je te fais un pari qu'à terme, Canonical retirera son copier/coller des flatpack.

si tu décides de migrer vers Debian :
- https://debian-facile.org/
- https://wiki.debian.org/fr/FrontPage
Le wiki de Debian va vraiment te rendre la vie plus facile pour la migration.
Si tu souhaites acquérir des connaissances complémentaires sur GNU/Linux : https://www.formatux.fr/formatux-formatux/index.html

à plus

ps : Ian Murdock
Modifié par niuxe (08 Feb 2022 - 16:55)

Bonjour,

Olivier C a écrit :
Je ne pense pas que les droits sur Linux fonctionnent comme cela. Cela voudrait dire qu'il faudrait donner les permissions à tout le répertoire racine pour commencer, ce qui n'est pas possible. Pour la petite histoire, je l'ai fais une fois par erreur de manip' et je ne pouvais plus accéder à la commande `sudo` : celle-ci est liées à un fichier racine dont les droits doivent être restreint.

Bref, à partir du moment où tu donne les droits sur un fichier, le chemin pour y accéder est forcément ouvert lui aussi. Ou alors quelque-chose m'échappe.

Ouch !

Mais bien sûr que si qu'il faut les droits d'accès sur les répertoires. Et changer les droits sur un fichier ne change pas les droits sur les répertoires qui le contiennent.

Tu ne t'en aperçois pas dans le cas général car souvent, les répertoires ont rwxr-xr-x (755) comme droit d'accès. Le "x" veut dire que tu peux "exécuter", c'est à dire en quelque sorte traverser le répertoire. Dans rwxr-xr-x, ça veut dire que le droit "x" est :
- pour le créateur (le 1er "x"),
- pour les utilisateurs du même groupe que le créateur (le 2e "x"),
- et pour tous les utilisateurs (le 3e "x").

Mais parfois, un répertoire peut se retrouver avec les droits 750 (rwxr-x---) ou 700 (rwx------) ou divers autres droits du même genre. Auquel cas, même s'il y a à l'intérieur de ce répertoire un fichier ayant pour droit 666 (ou 777 si tu veux, mais pour les fichiers de données 666 suffit pour faire la démonstration), tu n'y auras pas accès si ton utilisateur n'est pas dans le même groupe que le créateur du répertoire (dans le cas de droit 750 sur le répertoire) voire si ton utilisateur n'est pas le créateur (dans le cas de droit 700 sur le répertoire).

En résumé, quand tu ne peux pas accéder à un fichier avec un utilisateur donné, il faut bien vérifier si cet utilisateur a ou n'a pas le droit "x" sur tous les répertoires du chemin utilisé (que ce soit en allant depuis l'endroit où est rendu l'utilisateur vers le répertoire le plus englobant de ton chemin, ou depuis ce répertoire le plus englobant vers le fichier ciblé).

Amicalement,

PS: fais le test, tu crées dans un endroit que ne risque rien un repertoire et tu mets dedans un fichier avec des droits 666. Tu vérifies les droits sur le répertoire. Il y a des chances pour que ce soit 755 (mais bon, ça dépend des configurations système, il faut vérifier). Tu changes les droits sur ce répertoire (et seulement de ce répertoire) en 700. Tu changes d'utilisateur, et ensuite, tu essaies d'accéder au fichier par le moyen de ton choix. Enfin tu reviens nous dire si tu y a eu accès ou pas, parce qu'on n'est jamais sûr de rien.

@parsimonhi: je ne l'ai pas relevé. Bien vu

Bon, ce qui est sûr c'est que, effectivement, ça marche sur Debian 11 sans souci. Déjà. Je viens de tester pour voir (@niuxe ).

Pour les recommandations de Parsimonhi... je vais devoir te relire plusieurs fois. Je remets à demain. Merci.