@libremaster en fait j’ai toujours trouvé étrange qu’un tel mécanisme ne soit pas nativement présent dans le coeur de dolibarr … en regardant tous les autres projets dans lesquels j’ai un peu passé de temps j’ai noté que c’était un peu « le sens de l’histoire » (wordpress, gravcms, dokuwiki, nextcloud etc. proposent tous d’une manière ou d’une autre un mécanisme de « self upgrade »).
dokuwiki par exemple a un module complémentaire de mise à jour. Lorsqu’une upgrade est dispo un message est affiché à l’administrateur, je clique sur « upgrade » et le module de mise à jour me dit à chaque fois « attention, mettez à jour le module de mise à jour avant d’essayer de mettre à jour le coeur », c’est astucieux, en procédant ainsi le développeur se garde la possibilité de faire un correctif spécifique du process de mise à jour …
@ksar pour en revenir à ton code ce qui me semblerait le plus « urgent » serait d’implémenter le « nettoyage » je veut dire par la que - après lecture rapide - il semblerait que ton script fasse un unzip de la version demandée. C’est top, ça écrase tous les anciens fichiers mais par contre j’ai l’impression qu’il ne supprime pas les fichiers qui étaient présents dans la version précédente.
Le pb c’est que ça peut laisser des vieux fichiers potentiellement vulnérables sur certains aspect « sécu ».
J’aurais bien imaginé un truc du genre lecture du fichier xml de la version existante pour collecter tous les noms de fichiers qui étaient livrés par cette version(v16 par exemple), ensuite unzip de la v17, diff de la liste des fichiers par rapport à la nouvelle version et delete des fichiers « qui n’ont pas été livrés » dans le zip d’upgrade. C’est par exemple ce que fait dokuwiki.
Ça ne touchera pas aux fichiers manuellement ajoutés par l’utilisateur mais au moins ça supprimera les fichiers de l’ancienne version de dolibarr.
Quand à la collision avec le module sur le dolistore je ne l’avais pas vu … c’est effectivement une situation délicate :-/
Comment un tel script ou module gère-t-il les check de version php ?
Je viens de faire lexperience (en staging) dune mise à jour dune vieille base (v10) vers la develop. Ca a plante entre parce que je suis parti dune install en php 8, mais j’imagine que j’aurai pu avoir le problème inverse en étant sur un php 5.4…
Est ce que ce serait envisageable de prevoir un arret avant de tenter la mise à jour si la version ne correspond pas à la fourchette visée ?
L’idée d’un script léger et indépendant avant la première installation est d’éviter de devoir envoyer un gros fichier pour ceux qui n’ont pas une connexion internet rapide.
Ensuite, le processus de mise à jour (et pourquoi pas réparation/contrôle de l’installation) peut être intégré dans Dolibarr mais devrait pouvoir fonctionner seul sans aucune dépendance à des librairies Dolibarr pour le cas où quelque chose marche mal.
@libremaster 100% d’accord, c’est une évidence ! la proposition de mettre en module le script de @ksar n’était pas du tout exclusif dans ma tête mais complémentaire :
le script d’install d’un côté
le module de l’autre (avec proposition pour intégration dans le coeur) pour les upgrades
mais bon vu qu’il existe déjà un module sur le dolistore pour ça …
Tous ces systèmes ont un défault majeur, il n’est pas possible d’annuler une mise à jour de manière simple.
Il existe le gestionnaire de paquets nix qui permet de revenir aux états antérieurs, et de configurer son installation de manière déclarative.
Pendant la mise à jour, ne serait-il pas plus secure d’ajouter un fichier « upgrade.unlock », à partir de la v18, plutôt que de supprimer le « install.lock » ?
Pensez-vous le proposez en tant que PR sur le core ?
L’intégration dans le core n’est pas possible. En résumé : @eldy défend le fait qu’une mise à jour d’un CRM c’est quelque chose de sensible qui doit être fait uniquement par des gens qui ont les compétences pour le faire, et que donc ça ne doit pas être accessible en click-click-click.
Je comprends tout à fait ce point de vue, mais, comme pour chaque limitation mis en place, l’utilisateur « avancé » va chercher/trouver des moyens de contourner, et c’est là où mon script aide.
Quelques posts plus haut, on s’est posé la question de la mise en module de ce script.
Mais comme ça existe déjà : Mise À Jour
Je n’ai pas pris le temps de le faire.
C’est déjà la cas en v18: pour une mise à jour, il faut placer le fichier « upgrade.unlock » plutôt qu’effacer le « install.lock »
Supprimer le fichier install.lock fonctionnera aussi, mais cela rend aussi accessible temporairement l’usage des fonctions admin (install, création de compte, repair) alors qu’on a besoin que de l’accès aux fonction upgrade. Donc l’usage du upgrade.unlock est plus recommandé pour une mise à jour.
Toutes les logiciels qui ont un mécanisme de self upgrade ont aussi de gros problèmes de sécurité (tous).
En effet, conceptuellement, si on autorise un processus web à mettre à jour ses propres fichiers, alors cela veut dire qu’on donne les autorisations au propriétaire des processus du serveur web à modifier les fichiers, donc on autorise aussi n’importe qui ayant accès à une page de l’application, et qui sait exploiter une faille mineure de sécurité, a avoir accès à des fonctions destructrices (dès lors que le owner du serveur web a les droits pour mettre à jour des fichiers, alors potentiellement toute personne en remote qui peut solliciter une page, peu exécuter du code sous ce même owner et pourra donc aussi profiter de ces droits, et ceci sans bénéficier d’une grosse faille de sécurité, une toute petite injection HTML, JS, SQL amenant un dépôt de fichier suffira). 95% du travail du hackeur est donc offert sur un plateau.
Pour cette raison, il est recommandé que tout fichier des programmes de son installation de Dolibarr soit en lecture seule et non modifiables par le owner du serveur web (souvent www-data, mais peut etre forcé à d’autres valeur via certains modules de sécurité apache). De nombreuses applications web sont mal conçues et ne peuvent fonctionner en mode isolement des programmes et données fichiers car il y a des créations de fichiers temporaires dans le répertoire des binaires par exemple, ou juste parceque les développeurs n’ont pas pris en compte la sécurité. Ces applis sont un régal pour les hackeurs.
Dolibarr a la chance de ne pas avoir ce défaut. Il est donc possible de verrouiller tout le code application et ne donner le droit en écriture au niveau système que sur le répertoire des documents qui se trouve en dehors de la scope des page exécutable du serveur web (c’est aussi la que vont les fichiers temporaires).
De plus les mécanismes d’install/upgrade sont bloquées par défaut via un fichier dont l’accès requiert un accès au système de fichier et non un accès base (trop facile à pirater aussi dans ce cas). Ainsi un Dolibarr « hébergé » peut rester sous contrôle de l’hébergeur et non de l’utilisateur (si l’hébergeur le veut bien sur, il peut affaiblir ses protections pour donner full contrôle à l’utilisateur, mais cela doit être au choix de l’hébergeur).
Il est souhaitable de conserver cette force dans le fonctionnement dans le mode « par défaut ».
Pour compenser la contrainte (si toutefois cela est nécessaire), et permettre un upgrade « live » de l’appli web sans être admin système mais simple utilisateur web, il reste possible de fournir un module externe qui s’occuperait de ce travail, mais attention, c’est faire rentrer le loup dans la bergerie. Sur un système qui contient toutes les données de valeurs d’une entreprise, personnellement, je ne peux que décourager d’avoir recours à un tel module, mais si pour des raisons pratiques, c’est nécessaire, cela reste techniquement possible. Par contre l’avoir dans le coeur, en standard, signifierait intégrer volontairement une faille conceptuelle de sécurité, plus que critique et la publier de manière généralisé à tous.
Wordpress ou Prestashop, sur une installation standard, se pirate en quelques minutes grâces à ce côté permissif d’écrasement des fichiers de l’appli par elle même (et ce sera le cas pour tout appli web qui autorise son code à se modifier soi-même), il ne doit pas en être de même pour Dolibarr, du moins pas en « généralisé par défaut ». Mais en module externe, pourquoi pas…
Sur le plan plus général, il y a quand même un avantage à passer par un script de màj: la rapidité d’exécution.
Comme on l’a vu, certains d’entre nous on subit des attaques pendant leur màj au moment où l’install.lock était supprimer. Automatiser cette gestion de fichier permet de diminuer la fenêtre temporelle possible pour une attaque de ce genre.
De plus, avec un dossier custom modifiable, l’ensemble du fonctionnement du prog est de toute façon accessible via les hook, les triggers etc.
En fait, il faudrait priver l’utilisateur lambda de la possibilité d’installer qqch en recommandant de proteger le répertoir en écriture lors du fonctionnement normal. Et ne doit des droits que pour installer un module ou faire une maj. Ce qui n’a pas lieu tous les jours dans un système en prod.
