Est-il prudent de chown `/ usr / local`?
Je sais ce que /usr/local sert à - installer un logiciel pour la machine locale. Par défaut, root est propriétaire du répertoire. Cela signifie que pour y installer, vous devez utiliser Sudo. Pour une machine mono-utilisateur ou développeur, cela semble être une utilisation inutile de la commande. Par conséquent, ma question est-elle sûre de posséder /usr/local?
Par exemple, Homebrew pour OS X "Just Works" parce qu'ils possèdent /usr/local et en toute sécurité y installent leur logiciel sans utiliser Sudo.
De plus, si vous avez installé un logiciel compilé localement sur /usr/local, le logiciel a actuellement besoin de l'utilisateur root pour se modifier ou installer des plugins. Cela semble dangereux - je veux utiliser uniquement Sudo quand je sais EXACTEMENT ce qui va se passer.
Des avis?
Je ne peux pas recommander de devenir propriétaire de /usr/local; dans la plupart des situations, il est probablement moins sécurisé que d'utiliser Sudoname __.
Votre question suggère deux raisons pour lesquelles vous voudrez peut-être chown/usr/local.
La première consiste à éviter d'avoir à utiliser Sudopour installer le logiciel. Certains (tels que l’auteur de cette réponse ) pourraient lire que vous souhaitez travailler efficacement ou enregistrer les séquences de touches nécessaires pour taper Sudoet entrer votre mot de passe. Mais probablement lorsque vous dites "inutile", vous faites plutôt référence au principe du moindre privilège :
Par défaut,
rootest propriétaire du répertoire. Cela signifie que pour y installer, vous devez utiliserSudoname__. Pour une machine mono-utilisateur ou développeur, cela semble être une utilisation inutile de la commande.
J'entends/lis assez souvent des gens qui me disent/se plaint du type "je suis le seul à utiliser ce système, je n'ai donc pas besoin d'utiliser Sudoet de saisir un mot de passe". Pour les lecteurs qui sont de cet avis, et parce que c'est pertinent ici, rappelons-nous une raison de sécurité de base pour root to own choses.
La plupart des fichiers de programme installés sur un système Ubuntu ont le mode de fichier 755 ou la notation symbolique rwxr-xr-x, ce qui signifie que tout utilisateur ou programme peut les exécuter , mais uniquement le propriétaire des fichiers. , root, peut les modifier. (Techniquement, cela nécessite également que personne d'autre que root ne dispose de l'autorisation wsur le répertoire qui les contient, afin que les autres utilisateurs ne puissent pas les supprimer ou les déplacer.)
Cela signifie que vous, l'utilisateur humble, pouvez exécuter n'importe quel programme. Si vous essayez d'utiliser un programme pour faire quelque chose que vous n'avez pas l'autorisation de faire, comme effectuer une opération d'écriture sur un fichier appartenant à root, le programme affichera une erreur. Cela rend une faute de frappe dans une commande, une application buggy ou un code malveillant, moins susceptible de gâcher votre système - à moins qu'il ne soit exécuté en tant que root, il ne sera pas autorisé à le faire. Ceci est particulièrement utile lorsque vous exécutez des programmes qui interagissent avec Internet.
Si vous chown/usr/local, tout programme exécuté avec vos privilèges pourrait y écrire des fichiers, qui pourraient ultérieurement être exécutés en tant que root pour une raison quelconque, par exemple en remplaçant une autre commande du même nom. /usr/local/bin est dans la valeur par défaut $PATH , et dans Sudoname __ ' secure_path , et il vient avant ailleurs à la fois. Donc si j'ai deux exécutables
/usr/local/bin/chown
/bin/chown
quand j'exécute Sudo chown ..., , le chowndans /usr/local/bin sera exécuté .
Mais vous saviez probablement déjà tout cela, puisque votre deuxième raison est la sécurité:
De plus, si vous avez installé un logiciel compilé localement sur
/usr/local, le logiciel a actuellement besoin de l'utilisateur root pour se modifier ou installer des plugins. Cela semble dangereux - Je souhaite uniquement utiliserSudolorsque je sais EXACTEMENT ce qui va se passer.
Au cas où il serait nécessaire de le mentionner ici, il est absolument correct (selon le FHS de toute façon) d’installer le logiciel compilé localement sur /usr/local, mais la compilation elle-même doit être effectuée quelque part dans votre $HOME, sans Sudoname__, jusqu’à la dernière étape lorsque vous tapez Sudo make install ou équivalent.
Je pense que vous suggérez qu'en exécutant un programme installé dans /usr/local en tant que propriétaire non privilégié, vous pouvez utiliser les erreurs d'autorisation spécifiques générées lorsqu'il tente de se mettre à jour lui-même pour vérifier qu'il tente de modifier un autre emplacement de système de fichiers qui ne vous appartient pas. vous ne voulez pas, pour que vous puissiez l'empêcher de le faire.
Ceci pourrait être utile. L'implication est que vous faites confiance au programme pour faire tout ce qu'il veut dans /usr/local, mais pas ailleurs. S'il demande des autorisations élevées, vous pouvez refuser de le mettre à jour ou le désinstaller. Cela a du sens pour moi. Mais je pense qu'utiliser /usr/local comme une sorte de bac à sable de cette manière n'est probablement pas une bonne idée, ou du moins, il est peu probable qu'il s'agisse de la solution la plus sécurisée. Ce n'est pas un emplacement correctement isolé (/opt est un peu plus isolé, car ce n'est pas dans le défaut $PATH). Le programme peut écrire ou supprimer quelque chose dans /usr/local pour causer du tort. D'autres programmes (potentiellement mal écrits) que vous exécutez peuvent écrire et exécuter du code dont vous n'êtes pas au courant.
Si vous souhaitez permettre à un programme de se mettre à jour de manière sécurisée, vous devez probablement rechercher des alternatives (spécifiques au programme, comme avec python par exemple, ou vous pouvez rechercher une mise en œuvre instantanée ou similaire qui ou utilisez des conteneurs ou un VM pour tester des logiciels potentiellement dangereux) avant d'exposer un emplacement système (même relativement utilisateur) sur lequel les programmes exécutés par un utilisateur normal doivent écrire. Cela me semble avoir des effets imprévisibles comme autoriser des autorisations temporairement élevées pour des programmes avec Sudoname__.
Il est inhabituel que /usr/local ne soit pas la propriété de root. Mais vous pouvez changer le propriétaire comme vous le souhaitez.
Mais je vous conseille de vous assurer que /usr/local/sbin appartient toujours à root pour éviter un problème de sécurité. Les commandes ici ne sont généralement appelées que par root.
Pour les logiciels uniquement dont vous avez besoin , utilisez votre répertoire personnel au lieu de /usr/local.
Au lieu de changer la propriété de /usr/local ou d'avoir à exécuter des commandes en tant que root lorsque vous ne le souhaitez pas, vous devez simplement configurer vos générations pour qu'elles s'installent dans votre répertoire personnel au lieu de /usr/local. Cela résout tous les problèmes potentiels liés au changement de propriétaire de /usr/local, y compris la manière dont ses sous-répertoires bin et sbin se trouvent dans le chemin de root.
Si vous devez autoriser d'autres utilisateurs à exécuter votre logiciel, vous pouvez leur donner un accès. En fait, ils le seront probablement déjà car, par défaut, votre répertoire personnel a accès de lecture et d’exécution permissifs . (Si vous ne le souhaitez pas, vous pouvez le changer assez facilement, en utilisant simplement chmod sur les fichiers ou répertoires que vous voulez rendre privés et en modifiant éventuellement votre umask.)
Avec les logiciels installés dans votre répertoire personnel, les fichiers binaires qui seraient passés dans /usr/local/bin iront plutôt dans /home/username/bin. Vous obtiendrez d'autres sous-répertoires de votre répertoire de base correspondant aux sous-répertoires de /usr/local nécessaires au logiciel que vous installez. Cela se produit généralement automatiquement lorsque vous installez un logiciel à partir du code source.
Configurer vos constructions
La plupart des logiciels que vous construisez à partir du code source comportent une étape où vous exécutez:
./configure
Pour la grande majorité des logiciels livrés avec un script configure qui peut être exécuté de cette manière, la configuration de la construction pour l'installation est définie par défaut dans /usr/local lorsque vous exécutez finalement Sudo make install pour l'installer. La raison en est que cela équivaut implicitement à exécuter:
./configure --prefix=/usr/local
Pour configurer une construction à installer dans votre répertoire personnel, utilisez plutôt ceci:
./configure --prefix="$HOME"
En pratique, sous Ubuntu, les chemins des répertoires de base ne contiennent pas d'espaces, d'espaces ou de caractères qui seront traités spécialement par le shell, comme *. Ainsi, à moins que vous n'ayez configuré votre compte utilisateur, vous pouvez simplement taper:
./configure --prefix=$HOME
(Je ne recommande cependant pas de prendre l'habitude de cela pour écrire des scripts , cependant. En outre, sur certains autres systèmes d'exploitation - tels que macOS - c'est moins rare pour les chemins d'accès aux répertoires personnels des utilisateurs de contenir des espaces.)
Ou, si vous préférez, vous pouvez taper votre chemin de répertoire complet:
./configure --prefix=/home/username(Remplacez username par votre nom d'utilisateur actuel. Si, pour une raison quelconque, votre répertoire personnel n'est pas dans /home, vous devrez vous adapter en conséquence. )
Installer vos builds
Après avoir exécuté make, vous êtes peut-être habitué à exécuter Sudo make install, mais lorsque vous installez dans votre propre répertoire personnel, vous n'avez pas besoin de l'exécuter en tant que root. Vous pouvez donc - et le faire - omettez Sudo. Il suffit de courir:
make install
De même, pour les logiciels prenant en charge une cible uninstall:
make uninstall
C’est exactement ce que vous demandiez ... uniquement dans votre répertoire personnel, pas /usr/local.
Lancer vos programmes
Probablement le sous-répertoire bin de votre répertoire personnel est soit:
- déjà dans votre
$PATH, ou - sera dans votre
$PATHsi vous vous déconnectez puis vous reconnectez.
La raison en est que le fichier .profile de votre répertoire de base, qui contient les commandes qui s’exécutent lorsque vous vous connectez, le contient par défaut pour les comptes d’utilisateur créés dans la plupart des versions d’Ubuntu (y compris le compte d’administrateur initial créé lors de l’installation du système d’exploitation):
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
Ce code est exécuté lorsque vous vous connectez (car il est dans .profile) et place votre répertoire personnel bin dans $PATH uniquement s’il existe à ce moment-là. peut avoir besoin de se déconnecter puis de revenir.
Anciennes versions comme Ubuntu 14.04, ainsi que versions plus récentes comme Ubuntu 17.10, viennent avec. Cependant, Ubuntu 16.04, qui est probablement la version la plus populaire à ce jour, a ceci à la place:
# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"
Cela ajoute simplement le sous-répertoire bin de votre répertoire personnel --- ainsi que le sous-répertoire .local/bin - à votre $PATH, sans vérifier si ces répertoires existent réellement. Donc, si vous utilisez 16.04 ou si vous avez mis à niveau à partir de un système qui était 16.04 au moment de la création de votre compte utilisateur, le sous-répertoire bin de votre répertoire personnel est probablement déjà dans votre $PATH.
Votre fichier .profile est copié du répertoire /etc/skel lors de la création de votre compte d'utilisateur. Si votre compte utilisateur a été créé sur une ancienne version d'Ubuntu, il a obtenu cette version de .profile, qui n'a pas été modifiée - pour votre compte d'utilisateur - en passant à une version plus récente.
Une fois que le sous-répertoire bin de votre répertoire personnel est dans votre $PATH, vous pourrez exécuter les programmes dont les fichiers exécutables y sont installés simplement en tapant leurs noms, comme vous le feriez avec les programmes installés par le gestionnaire de paquets d'Ubuntu ou installés dans /usr/local.
L'option .local
Vous avez peut-être remarqué que le fichier par défaut .profile pour les comptes d'utilisateurs créés dans certaines versions d'Ubuntu, y compris dans 16.04 comme décrit ci-dessus, ajoute non seulement $HOME/bin à votre chemin, mais aussi $HOME/.local/bin. Si votre .profile n’ajoute pas cela, mais que vous le voulez , vous pouvez simplement le modifier.
Bien que souvent utilisé pour stocker les paramètres et les données en cache , vous pouvez également installer un logiciel dans le sous-répertoire .local de votre répertoire de base. Vous devriez vous sentir libre de le faire car, du point de vue de la convivialité et de la sécurité, --prefix="$HOME/.local" est similaire à --prefix="$HOME".
Rappelez-vous que les fichiers et les répertoires commençant par . ne sont pas affichés par défaut dans les navigateurs graphiques (utilisez Ctrl+H pour les afficher et les repasser) ou à l’aide de la commande ls (transmettez le drapeau -A ou -a pour les afficher). Cela peut ne pas être ce que vous voulez, ou ce peut être exactement ce que vous voulez. C'est une question de préférence personnelle.
Cependant, j'ai observé que certains gestionnaires de packages automatisés basés sur une source qui construisent et installent des logiciels dans son répertoire personnel utilisent $HOME/.local. Je ne sais pas à quel point c'est courant - j'espère approfondir cette question et mettre à jour cette réponse - mais vous préférerez peut-être simplement utiliser $HOME pour les éléments que vous compilez manuellement. De cette façon, il sera clair d'où viennent les choses. Et en cas de collision, le logiciel risque toujours de coexister de manière acceptable.
Vous pouvez également délibérément installer certains logiciels dans $HOME/.local et d'autres logiciels dans $HOME. C'est à vous. Le répertoire bin qui apparaît en premier dans votre variable d’environnement $PATH est celui à partir duquel une commande sera exécutée, s’il existe des commandes du même nom dans les deux cas.
Le crédit va à Zanna et Videonauth pour soulignant les erreurs dans un version précédente = de cette réponse, en ce qui concerne les versions Ubuntu qui ont quel code par défaut dans .profile, et m'aider à corriger eux (voir aussi ici ).
Si Sudo est un inconvénient, mettez simplement à jour/etc/sudoers afin que vous n'ayez pas à saisir votre mot de passe pour exécuter Sudo. Je pense que c'est une meilleure solution que de changer le propriétaire de/usr/local.