V14 Permissions sur les fichiers du répertoire racine (chmod)

Je serais d’avis de tout réinstaller, quel bordel !

Je ne suis pas sûr que ce soit un souci de « tout réinstallé » j’ai le même souci sur une install from scratch.
C’est, je pense, une configuration standard des droits sur les fichiers/dossiers à modifier, ou une demande trop contraignante de Dolibarr sur ces droits.
Le mieux serait qu’une personne expérimentée en config Apache et droit linux nous donne les prérequis à mettre en place pour avoir un environnement sécurisé sans pour autant « tout bloquer ».

Le problème est quand même étrange. Les fichiers de l’archive Dolibarr ont les bons droits par défaut. Il faut faire attention à bien décompresser l’archive sur un système linux (à distance sur le serveur), pas localement sur un windows et transférer ensuite sinon les droits sont perdus.

Voici un tuto que j’avais fait, il n’est pas pour Apache mais pour NGINX mais le déroulement devrait être semblable, je ne touche pas aux droits des fichiers Dolibarr bien que je prépare le répertoire d’accueil, l’utilisateur avec un peu de sécurité d’accès : Comment installer Dolibarr sur un VPS OVH Debian 11

1 « J'aime »

Est-ce qu’une install en local pour vérifier les droits de base sur les dossiers/fichiers attribués par Dollibar d’origine provenant de la décompression zip serait une bonne idée? Parce qu’effectivement, comme je n’ai pas pu décompresser le fichier zip directement sur le serveur mutualisé, j’ai décompressé sur ma machine → et ensuite envoyé sur le ftp. Le problème vient peut-être de là?

Sympa le tuto sous NGINX :+1:
Je vais refaire un essai d’Install depuis zéro pour voir si ça change.
Peux-tu nous donner les droits que tu as sur tes dossiers / sous-dossiers / fichiers ?
Si je ne me trompe pas, tout doit être identique dans le htdocs sauf le conf.php (et le install.lock dans documents/)

En effet ton envoi par FTP a du faire « sauter » les droits, il faut au moins aller redéfinir ceux des 2 fichiers vu plus haut.
Pour un serveur mutualisé jette un coup d’œil sur le site de @libremaster il y a un tuto spécifique apparemment : Comment installer Dolibarr v14 dans un hébergement mutualisé OVH ?
Peut-être que cela suffit pour ne pas avoir les warning.

Merci pour les infos. Je vais regarder!

Pour info j’ai été obligé de repasser le dossier custom en 755 sinon il n’est pas possible d’ajouter un module via l’interface web

sudo chmod -R 755 /var/www/my-dolibarr/htdocs/custom/

Cela n’influ pas sur l’alerte de sécurité

C’est vrai que le module builder nécessite que l’utilisateur du serveur web ait le droit d’écrire dans custom. Quoi qu’il arrive, le module builder n’est pas vraiment fait pour être utilisé en production (typiquement, on développe un nouveau module en local, pas en prod).

Je ne parlais pas du Module Builder (qui a sûrement également besoin des droits), mais de l’onglet « Déployer/Installer un module externe » qui sert à ajouter un nouveau module téléchargé depuis le Dolistore.
Il n’est utilisable qu’avec un droit d’écriture dans htdocs/custom/ ce qui paraît logique puisqu’il va aller installer le module dedans

Je viens de le faire sur une nouvelle installation en v14. Je confirme que les commandes permettent d’être conforme par rapport au diag de décurité.

sudo chmod -R 555 /var/www/my-dolibarr/htdocs/
sudo chmod -R 400 /var/www/my-dolibarr/documents/install.lock
sudo chmod -R 400 /var/www/my-dolibarr/htdocs/conf/conf.php
sudo chmod -R 755 /var/www/my-dolibarr/htdocs/custom/

1 « J'aime »

Les fichiers ont du coup le droit d’exécution ce qui n’est pas nécessaire.
Peut-être il faut corriger :

sudo chmod -R a-x /var/www/my-dolibarr/htdocs/
sudo chmod -R a+X /var/www/my-dolibarr/htdocs/

Seuls les répertoires auront le droit ‹ x ›.
Entre les deux commandes, Dolibarr sera bloqué temporairement
Le X majuscule dit que seuls les répertoires auront le droit x.

Bonjour,

j’ai du mal à comprendre la logique de votre script.

Vous commencez par ajouter des droits d’exécution avec du chmod -R 555 et chmod -R 755 et ensuite vous supprimez les droits d’execution avec chmod -R a-x et vous recorrigez ensuite les répertoires avec chmod -R a+X

Autre chose chmod -R 755 sur le répertoire documents c’est pas une bonne idée.

@Petit_bill merci pour la tentative de centralisation des informations sur les droits.
@hop je pense que l’erreur sur les chmod vient d’une mauvaise compréhension du message de @libremaster un peu plus haut.

Ce qui serait vraiment top ce serait d’avoir un script de remise à plat des droits qui soit validé par les responsables du projet et par des « sachant » en droits Linux.

Pour ma part je ne m’estime pas assez connaisseur sur ce domaine pour proposer une solution qui soit conforme aux attentes de la page de diagnostic tout en garantissant la sécurité maximale des accès du serveur Apache.

En tout cas merci à ceux qui partagent et apportent une tentative de solution :+1:

Fournir un script va donner l’illusion qu’une installation est correctement protégée si on execute ce script sans comprendre ce qu’il fait.

Oui, mais ne rien communiquer et laisser les personnes faire n’importe quoi avec des droits en 777 ou de mauvaises configurations sera d’autant plus dommageable.

J’ai l’impression que les personnes qui ont la compétence ne souhaitent pas transmettre leur savoir. C’est bien dommage sur un projet Open-Source.

Bonjour
Effectivement je rejoins @hop .
Ensuite penser qu’un script peut être passe-partout c’est croire qu’on est en sécurité alors que non. Selon le serveur l’hebergement, ça change. Des fois on a même pas de terminal. Expliquer à un néophyte la gestion des droits n’est pas simple.
Ce n’est pas qu’une histoire de partage. Peut être une histoire de responsabilité ?
Dans certains cas, mieux vaut dire de se rapprocher d’un pro ,c’est plus sûr.
@+

1 « J'aime »

Ce script n’est pas un bon exemple car il implémente des mauvaises pratiques.

Mes commandes avaient pour but de corriger un problème qui n’est pas supposé être là au départ. Ce script crée le problème et le corrige en même temps.

Puis l’utilisation de l’utilisateur www-data montre un problème plus important dans le procédé d’installation. On évite autant que possible de lancer Dolibarr avec l’utilisateur du serveur web.

j’ai donc supprimer le post

désolé

La question est : pourquoi les gens font n’importe quoi en copiant/collant le premier bout de commande shell trouvé sur un forum ? Si on ne comprend pas ce que fait une commande pourquoi l’éxecuter dans un terminal ?

Sécuriser un serveur et une application web ce n’est pas une compétence qu’on apprend en lisant quelques posts sur un forum. Cela demande de l’investissement personnel en temps, de la lecture de nombreuses documentations etc, etc.
Le web est rempli de ressources pour acquérir ces compétences, et c’est accessible avec une requête dans un moteur de recherche.