Est-il sûr de chown `/ usr / local`?

Je sais à quoi ça /usr/localsert - installer un logiciel pour la machine locale. Par défaut, rootpossède le 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 supplémentaire inutile de la commande. Par conséquent, ma question - est-il sûr pour moi de posséder /usr/local?

Par exemple, Homebrew pour OS X "Just Works" parce qu'ils possèdent /usr/localet installent leur logiciel en toute sécurité sans utiliser de sudo.

De plus, si vous avez installé un logiciel compilé localement /usr/local, le logiciel a actuellement besoin de root pour se modifier ou installer des plugins. Cela semble dangereux - je ne veux l'utiliser que sudolorsque je sais exactement ce qui va se passer.

Des avis?

Je ne peux pas recommander de devenir propriétaire de /usr/local; pour la plupart des situations, c'est probablement moins sûr que d'utiliser sudo.

Votre question suggère deux raisons pour lesquelles vous voudrez peut-être chown /usr/local.

Le premier est d'éviter d'avoir à utiliser sudopour installer des logiciels. Certains (comme l'auteur de cette réponse ) pourraient lire que vous voulez travailler efficacement ou enregistrer les frappes nécessaires pour taper sudoet entrer votre mot de passe. Mais probablement quand vous dites «inutile», vous faites plutôt référence au principe du moindre privilège :

Par défaut, rootpossède le 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 supplémentaire inutile de la commande

J'entends / lis souvent des gens qui s'opposent / se plaignent du type "Je suis le seul à utiliser ce système, donc je ne devrais pas avoir besoin d'utiliser sudoet d'entrer 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 que root possède ses propres objets.

La plupart des fichiers programme installés sur un système Ubuntu ont le mode fichier 755, ou en notation symbolique rwxr-xr-x, ce qui signifie que tout utilisateur ou programme peut les exécuter , mais seul le propriétaire des fichiers, root, peut les modifier. (Techniquement, cela nécessite également que personne d'autre que root n'ait l' wautorisation sur le répertoire qui les contient, de sorte que les autres utilisateurs ne peuvent pas les supprimer ou les déplacer.)

Cela signifie que vous, l'humble utilisateur, 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, cela provoquera une erreur. Cela rend une faute de frappe dans une commande, une application boguée ou un code malveillant, moins susceptible de gâcher votre système - à moins qu'il ne s'exécute en tant que root, il ne sera pas autorisé à le faire. Ceci est particulièrement utile lors de l'exécution de programmes qui interagissent avec Internet.

Si vous chown /usr/local, n'importe quel programme fonctionnant avec vos privilèges pourrait y écrire des fichiers, qui pourraient plus tard ê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/binest par défaut $PATH, et dans sudo's secure_path, et il précède les autres emplacements dans les deux. Donc, si j'ai deux exécutables

/usr/local/bin/chown
/bin/chown

quand j'exécute sudo chown ..., l' chownin /usr/local/binsera exécuté .

Mais vous saviez probablement déjà tout cela, car votre deuxième raison concerne la sécurité:

De plus, si vous avez installé un logiciel compilé localement /usr/local, le logiciel a actuellement besoin de root pour se modifier ou installer des plugins. Cela semble dangereux - je ne veux l'utiliser que sudolorsque je sais exactement ce qui va se passer.

_{Juste au cas où il /usr/localserait nécessaire de le mentionner ici, il est tout à fait correct (selon le FHS de toute façon) d'installer un logiciel compilé localement , mais la compilation elle-même devrait être effectuée quelque part dans votre $HOME, sans sudo, jusqu'à la dernière étape lorsque vous tapez sudo make installou équivalent.}

Je pense que vous suggérez qu'en exécutant un programme installé en /usr/localtant que propriétaire non privilégié, vous pourriez utiliser des erreurs d'autorisation spécifiques levées lorsqu'il essaie de se mettre à jour pour voir qu'il essaie de modifier un autre emplacement du système de fichiers qui ne vous appartient pas d'une manière que vous je ne veux pas, afin que vous puissiez l'empêcher de le faire.

Cela pourrait être utile. L'implication est que vous faites confiance au programme pour faire tout ce qu'il veut à l'intérieur /usr/local, mais pas ailleurs. S'il demande des autorisations élevées, vous pouvez refuser de le mettre à jour ou le désinstaller. Cela me semble logique. Mais je pense qu'essayer de l'utiliser /usr/localcomme une sorte de bac à sable de cette manière n'est probablement pas une bonne idée, ou du moins il est peu probable que ce soit la solution la plus sûre. Ce n'est pas un emplacement correctement isolé ( /optest un peu plus isolé, car il n'est pas dans la valeur par défaut $PATH). Le programme peut écrire ou supprimer quelque chose /usr/localpour causer du tort. D'autres programmes (potentiellement mal écrits) que vous exécutez peuvent y écrire et exécuter du code que vous ne connaissez pas.

Si vous craignez d'autoriser un programme à se mettre à jour en toute sécurité, vous devriez probablement rechercher des alternatives (spécifiques au programme peut-être, comme avec python par exemple, ou vous pouvez rechercher un snap ou une implémentation similaire qui convient à vos besoins, ou utiliser des conteneurs ou une machine virtuelle pour tester des logiciels potentiellement dangereux) avant d'exposer un emplacement système (même relativement utilisateur) auquel les programmes exécutés par un utilisateur normal doivent écrire. Cela me semble aussi susceptible d'avoir des effets imprévisibles que d'autoriser temporairement des programmes avec des autorisations élevées sudo.

Il est inhabituel de /usr/localne pas appartenir à root. Mais vous pouvez changer de propriétaire comme vous le souhaitez.

Mais je vous conseille de vous assurer qu'il /usr/local/sbinappartient toujours à rootafin d'éviter un problème de sécurité. Les commandes ici ne sont généralement invoquées que par root.

Pour les logiciels dont vous avez uniquement besoin, utilisez votre répertoire personnel au lieu de /usr/local.

Au lieu de changer la propriété de /usr/localou d'avoir à exécuter des commandes en tant que root lorsque vous ne le souhaitez pas, vous devez simplement configurer vos versions afin qu'elles s'installent dans votre répertoire personnel au lieu de /usr/local. Cette adresse tous les problèmes potentiels liés à l' évolution de la propriété de /usr/local, y compris la façon dont ses binet les sbinsous - répertoires sont dans rootle chemin « .

Si vous devez autoriser d'autres utilisateurs à exécuter votre logiciel, vous pouvez leur donner accès. En fait, ils le seront probablement déjà, car par défaut votre répertoire personnel a un accès permissif en lecture et en exécution . (Si vous ne le souhaitez pas, vous pouvez le modifier assez facilement, simplement en utilisant chmodn'importe quel fichier ou répertoire que vous souhaitez rendre privé et éventuellement en changeant le vôtre umask.)

Avec un logiciel installé dans votre répertoire personnel, les fichiers binaires qui y seraient entrés le /usr/local/binseront à la place . Vous obtiendrez d'autres sous-répertoires de votre répertoire personnel correspondant aux sous-répertoires dont le logiciel que vous installez a besoin. Cela se produit généralement automatiquement lorsque vous installez un logiciel à partir du code source./home/username/bin/usr/local

Configuration de vos builds

La plupart des logiciels que vous créez à partir du code source ont une étape où vous exécutez:

./configure

Pour la grande majorité des logiciels livrés avec un configurescript pouvant être exécuté de cette manière, la configuration par défaut est configurée pour l'installation à l'intérieur /usr/locallorsque vous exécutez finalement sudo make installpour l'installer. La raison en est qu'elle est implicitement équivalente à l'exécution:

./configure --prefix=/usr/local

Pour configurer une build pour l'installation dans votre répertoire personnel, utilisez plutôt ceci:

./configure --prefix="$HOME"

En pratique, dans Ubuntu, les chemins du répertoire personnel ne contiennent pas d'espaces, d'autres espaces ou d'autres caractères qui seront traités spécialement par le shell comme *, donc à moins que vous n'ayez configuré votre compte d'utilisateur de manière assez étrange, vous pouvez simplement taper:

./configure --prefix=$HOME

(Je ne recommande pas de prendre l'habitude de cela pour écrire des scripts , cependant. En outre, sur certains autres systèmes d'exploitation - tels que macOS - il est moins rare que les chemins vers les répertoires personnels des utilisateurs contiennent des espaces.)

Ou si vous préférez, vous pouvez taper le chemin complet de votre répertoire personnel:

./configure --prefix=/home/username

(Remplacez usernamepar votre nom d'utilisateur réel, bien sûr. Si, pour une raison quelconque, votre répertoire personnel n'est pas dans, /homevous devrez vous ajuster en conséquence.)

Installer vos builds

Après avoir couru make , vous pouvez être habitué à l'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 devriez - omettre sudo. Exécutez simplement:

make install

De même, pour les logiciels qui prennent en charge une uninstallcible:

make uninstall

C'est exactement ce que vous demandiez ... juste dans votre répertoire personnel, non /usr/local.

Exécuter vos programmes

ProbablementLe binsous - répertoire de votre répertoire personnel est soit:

• déjà dans votre $PATH , ou
• sera dans votre $PATH si vous vous déconnectez et vous reconnectez.

La raison en est que le .profilefichier de votre répertoire personnel, qui contient des commandes qui s'exécutent lorsque vous vous connectez, contient celui-ci par défaut pour les comptes d'utilisateurs créés dans la plupart des versions d'Ubuntu (y compris le compte d'administrateur initial créé lorsque vous installez le 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 s'exécute lorsque vous vous connectez (car il est présent .profile) et place votre binrépertoire personnel dans$PATH uniquement s'il existe à ce moment-là. C'est pourquoi vous devrez peut-être vous déconnecter puis vous reconnecter.

Les versions plus anciennes comme Ubuntu 14.04, ainsi que les versions plus récentes comme Ubuntu 17.10, viennent avec cela. 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 binsous - répertoire de votre répertoire personnel --- ainsi que le .local/binsous-répertoire - à votre $PATH, sans vérifier si ces répertoires existent réellement. Donc, si vous utilisez 16.04, ou si vous avez effectué une mise à niveau à partir d' un système qui était 16.04 lorsque votre compte d'utilisateur a été créé, alors lebin sous répertoire de votre répertoire personnel est probablement déjà dans votre $PATH.

Votre .profilefichier est copié depuis le/etc/skel répertoire lors création de votre compte utilisateur. Si votre compte d'utilisateur a été créé sur une ancienne version d'Ubuntu, il a obtenu cette version de .profile, et il n'a pas été modifié - pour votre compte d'utilisateur - par la mise à niveau vers une version plus récente.

Une fois le binsous - répertoire de votre répertoire personnel dans votre$PATH , vous pourrez exécuter des programmes dont les fichiers exécutables y sont installés en tapant simplement leurs noms, tout comme vous pourriez le faire avec des programmes installés par le gestionnaire de paquets d'Ubuntu ou installés à l'intérieur /usr/local.

le .local option

Vous avez peut-être remarqué que le .profilefichier par défaut 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 vous .profilen'ajoutez pas cela, mais que vous voulez , vous pouvez simplement le modifier dans.

Bien que souvent utilisé pour stocker des paramètres et des données en cache , vous pouvez également installer des logiciels dans le .localsous - répertoire de votre répertoire personnel. Vous devriez vous sentir libre de le faire, car du point de vue de la convivialité et de la sécurité, --prefix="$HOME/.local"c'est similaire à --prefix="$HOME".

N'oubliez pas que les fichiers et répertoires commençant par .ne sont pas affichés par défaut dans les navigateurs de fichiers graphiques (utilisez Ctrl+ Hpour les afficher et les afficher à nouveau) ou par la lscommande (passez l' indicateur -Aou -apour les afficher). Ce n'est peut-être pas ce que vous voulez, ou 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 la source qui construisent et installent des logiciels dans leur répertoire personnel utilisent $HOME/.local. Je ne sais pas à quel point cela est courant - j'espère approfondir et mettre à jour cette réponse - mais vous préférerez peut-être simplement l'utiliser $HOMEpour les choses que vous compilez manuellement. De cette façon, il sera clair d'où viennent les choses. Et en cas de collision, le logiciel est susceptible de coexister de manière acceptable.

Vous pouvez également installer délibérément certains logiciels dans $HOME/.localet d'autres logiciels dans $HOME. C'est à vous. Le binrépertoire qui apparaît en premier dans votre $PATHvariable d'environnement est celui à partir duquel une commande sera exécutée, dans le cas où des commandes du même nom existent dans les deux.

Le crédit va à Zanna et Videonauth pour signaler les erreurs dans une version précédente de cette réponse, au sujet de laquelle les versions d' Ubuntu ont un code qui par défaut .profileet me aider à corriger les (voir aussi ici ).

Si sudo est un tel inconvénient, mettez simplement à jour / etc / sudoers pour ne pas avoir à entrer votre mot de passe lorsque vous exécutez sudo. Je pense que c'est une meilleure solution que de changer le propriétaire de / usr / local.