Salut,
Pour le risque d’exécuter des scripts d’installation avec sudo
, quels qu’ils soient, je l’entends souvent dire mais je pense que ça se débat : d’abord parce que la séparation entre les fonctionnalités « essentielles » des systèmes Linux n’est sans doute pas aussi forte qu’elle l’était au début de l’époque de certains UNIX ; sur une machine à vocation d’utilisation personnelle, les principaux ravages que tu peux faire sont en touchant au dossier personnel (dotfile) du navigateur, et à l’autostart de l’environnement de bureau (voire celui de FreeDesktop), or, tous deux se trouvent dans le dossier personnel de l’utilisateur et aucun n’est protégé par les droits root. Pas grand chose ne requiert l’accès root en termes de nuisances potentielles, si ce n’est l’installation d’un rootkit un peu avancé, alors qu’un cryptominer, voire un keylogger utilisant l’API XKB s’installe sans encombres dans la partie non-protégée du système.
De plus, si les gens installent du contenu venant d’inconnus, en règle générale, ce sera le plus souvent pour l’exécuter ensuite, y compris s’il demande une élévation de privilèges. Dans les faits, il faut reconnaître que le fonctionnement de l’open source repose, en grande partie, sur la confiance entre les gens, et jusqu’ici ça fonctionne globalement très bien. Même si le principe de vouloir conserver une séparation des privilèges plus forte que ce qui est pratiqué par les gens aujourd’hui se défend.
L’installation d’outils et de bibliothèques dans /usr/local
(telle que permise par l’exécution de pip
en tant que root) relève davantage de la simplicité sur la plupart des configurations, en fait. C’est une question d’ergonomie et d’universalité qui, c’est vrai, se fait au détriment de la séparation des privilèges.
Concernant le fait d’utiliser python3.7 -m pip
plutôt que python3
, c’est par rapport au fait que sous Ubuntu LTS (18.04 Bionic), le Python par défaut est toujours un 3.6, et les différents modules Python fournis par les dépôts du système vont s’installer dans /usr/lib/python3
, or, l’outil concerné ne peut utiliser que des versions plus récentes de certains paquets qui sont fournies par pip
, mais pas par les dépôts système d’Ubuntu, et les versions fournies par Ubuntu ne sauraient être désinstallées sans causer des problèmes de dépendances, de même que l’exécutable de Python 3.6 (python3
) refusera normalement de considérer que les versions installées par pip
doivent être préférées à celles installées par Ubuntu. Ici, l’astuce est d’installer des modules dans le dossier plus spécifique /usr/local/lib/python3.7
, ce qui permettra de ne pas privilégier les modules fournis par les dépôts d’Ubuntu dans le dossier python3
, et permettre l’exécution correcte de l’outil (ce qui est un peu capillotracté sur le principe, mais fonctionnera chez le plus de monde).
Cordialement,