Est-ce que mes permissions sur / usr / local / sont correctes?

88

J'utilise HomeBrew pour mes besoins en matière de port (semble un peu plus «propre» que MacPorts).

Je peux installer sans sudoing (ce qui est génial), mais l’étape de liaison semble en avoir besoin ( /usr/local/share/man/man3appartient à root).
Un guide que j'ai trouvé suggère chown /usr/localde le faire récursivement

sudo chown -R `whoami` /usr/local

Est-ce sûr ou… est-ce une mauvaise idée?

Aussi: mes autorisations sont-elles correctes?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis
terminal macports permission homebrew Agos
la source
5
Voici comment Homebrew doit être utilisé. Certaines personnes peuvent être en désaccord mais le développeur principal dit de faire les choses de cette façon.
Mike McQuaid
1
Légèrement meilleure alternative à votre chown: sudo chown -R :admin /usr/local. De cette façon, cela fonctionnera de la même manière pour tout utilisateur administrateur de la machine. Cependant, vous devrez peut-être également vous exécuter sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+pour vous assurer que le groupe dispose du même accès en écriture que l'utilisateur.
Slipp D. Thompson
12
"Je vais utiliser homebrew, c'est plus propre que macports. Oh, regardez ce gâchis de permissions mal défini. Je vais vérifier dans Stack Overflow. Oh, voici un petit tour qui va à l'encontre des meilleures pratiques Unix et de ce que les mises à jour du système d'exploitation essaient à appliquer. Parfait! ". Mois plus tard: "Hé, comment ce malware a-t-il été installé?"
hmijail
Le problème que j'ai avec cette approche est que cela signifie que seul le compte d'utilisateur qui installe Homebrew peut l'utiliser. J'ai un Mac avec plusieurs comptes que j'utilise pour séparer les projets professionnels des projets personnels (par exemple). Si je suis connecté au mauvais compte, je ne peux pas utiliser l'installation de brassage. J'ai choisi cette voie pour éviter les dangers liés à l'utilisation de root, mais je ne suis pas convaincu que ce soit la meilleure approche.
Auspice
@MikeMcQuaid Je trouve intéressant que Homebrew ait finalement admis sa faute et que, dans la nouvelle version parue il y a une semaine ou deux, les autorisations par défaut
soient

Réponses:

37

Il est généralement préférable de garder les autorisations aussi strictes que possible. Garder la /usr/localpropriété rootsignifie que seuls les processus qui s'exécutent en tant que root/ sudo(ou demandent à l'utilisateur administrateur via la boîte de dialogue d'autorisation Apple) peuvent écrire dans cette zone. Ainsi, un téléchargement de processus doit vous demander un mot de passe avant de corrompre des fichiers.

Mais comme vous le dites, il est plus difficile d’ajouter de nouveaux programmes.

Je suis en mesure d’exécuter sudo, car vous installez des choses moins souvent que de les exécuter, mais vous devez être certains que le processus de construction ne change rien du tout.

Si vous voulez éviter le sudo ~/usr/local, j'installerais Homebrew et modifierais votre chemin, manpath, etc. pour inclure les répertoires en-dessous.

Un meilleur moyen consiste à créer un autre utilisateur, par exemple, homebrewet à créer un répertoire appartenant à cet utilisateur. Ensuite, installez là en utilisant sudo -U homebrew. Les autres utilisateurs auront l’avantage de ne pas pouvoir écraser d’autres fichiers, car ils ne fonctionnent pas en tant que root et les autres programmes ne peuvent pas affecter l’homebrew. (Je remarque que la FAQ Homebrew suggère ce nouvel utilisateur si vous êtes dans un "environnement multi-utilisateur". Je dirais que toute machine Unix, y compris macOS, est un environnement multi-utilisateur)

Cependant, comme le dit le wiki Homebrew, les recettes ne trouvent pas tous les cas de /usr/localet les remplacer par le répertoire choisi je soupçonne que nous sommes coincés avec /usr/local.

utilisateur151019
la source
1
+1 pour garder les autorisations strictes, et modifier $PATHet $MANPATHinclure les annuaires d'utilisateurs. Si les programmes installés ne nécessitent pas d'installation à l'échelle du système, c'est une bien meilleure alternative.
Samedi
3
+1 et réponse acceptée pour «garder les autorisations aussi strictes que possible». Faire brew doctor(suggéré ci-dessous) m'a dit que je n'avais qu'à chown les répertoires d'hommes partagés ... assez sûrs pour moi.
Agos le
1
Une solution de compromis, du moins pour les personnes qui se soucient suffisamment de sécurité pour ne pas s'exécuter en tant qu'administrateur, consiste à modifier la propriété du groupe et les autorisations afin que seuls les administrateurs puissent écrire dans / usr / local. Voir la réponse de Kenorb.
hmijail
2
@Mark Je trouve intéressant que Homebrew ait finalement admis sa faute et que, dans la nouvelle version parue il y a une semaine ou deux, les autorisations par défaut aient été restaurées sur / usr / local
oemb1905.
48

J'utilise aussi Homebrew et peux confirmer que c'est totalement sans danger. Citant la page Installation de la FAQ officielle de Homebrew :

Faites-vous une faveur et choisissez /usr/local

  1. C'est plus facile,
    /usr/local/bin c'est déjà dans votre PATH.

  2. C'est plus facile Des
    tonnes de scripts de construction se cassent si leurs dépendances ne sont ni dans / usr ni dans / usr / local. Nous corrigeons cela pour les formules Homebrew (bien que nous ne le testions pas toujours), mais vous constaterez que de nombreux scripts d'installation RubyGems et Python se cassent, ce qui est en dehors de notre contrôle.

  3. C'est sûr
    qu'Apple s'est conformé à POSIX et a laissé ce répertoire pour nous. Ce qui signifie qu'il n'y a pas de /usr/localrépertoire par défaut, il n'y a donc pas lieu de s'inquiéter de foirer les outils existants.

Si vous envisagez d'installer des gemmes qui dépendent de brasseries, alors épargnez-vous des tracas et installez-les dans /usr/local!

Il n’est pas anodin de dire à gem de rechercher dans les annuaires non standard des en-têtes et des dylibs. Si vous choisissez /usr/local, tout "fonctionne"!

Je vais juste ajouter que faire des choses en tant que root est une très mauvaise idée , donc chowning /usr/localnon seulement me semble raisonnable (ce n'est pas un système dir sur Mac OS X), mais sain d' esprit .

Vos autorisations ne sont pas correctes (pas encore). Il suffit d’exécuter la commande que vous avez énumérée et tout ira bien.

Si vous avez d'autres problèmes, rappelez-vous, ils brew doctorpeuvent vous aider!

Carmine Paolino
la source
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
bmike
7
Le chat est parti, ce qui est dommage. Donc, au risque de répéter l'histoire, je laisserai mon commentaire ici: que cela soit fait ne signifie pas que cela est sans danger.
hmijail
4
L'essentiel du tableau est bien que c'est ce que suggère Homebrew pour des raisons qui expliquent son erreur
user151019 le
1
brew doctorc'est tout simplement génial.
Utku
5
@Carmine Paolino Je trouve intéressant que Homebrew ait finalement admis sa faute et que, dans la nouvelle version parue il y a une semaine ou deux, les autorisations par défaut aient été restaurées sur / usr / local
oemb1905.
9

Si vous utilisez Homebrew, vous devez donner l'autorisation d'écriture à un groupe spécifique (un adminou plusieurs staff), afin que les fichiers puissent être partagés entre les utilisateurs appartenant à ce groupe.

Par exemple:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Puis assignez les utilisateurs qui devraient avoir accès à la brewcommande à ce groupe (vérifiez vos groupes via:) id -Gn.

Ensuite, lorsque vous travaillez avec brew, ne le lancez pas sudo.

Si vous rencontrez toujours un problème d’autorisation, exécutez-le brew doctorpour résoudre le problème.

Kenorb
la source
+1 pour donner une solution réelle, plus sage, même si ce n’est pas vraiment fini. Par exemple: ajouter un utilisateur au groupe d'administrateurs au niveau BSD? Cela ne va-t-il pas gâcher le concept d’utilisateurs Admin de OS X?
hmijail
Pour mémoire, j'ai suivi ces instructions, mais je viens d'utiliser mon utilisateur administrateur existant sous OS X créé par l'interface graphique OS X au lieu d'ajouter quelqu'un à n'importe quel groupe de la CLI. Cela fonctionne: pour pouvoir exécuter des commandes d'infusion, je dois d'abord le faire su myAdminUser, puis tout fonctionne comme prévu. Mais bien sûr, cette solution ne donnera aucune sécurité aux personnes qui, de toute façon, exécutent déjà un utilisateur administrateur à tout moment.
hmijail
C'est probablement la meilleure façon de faire, je suis d'accord avec @kenorb
pixel 67
7

Pour ce que cela vaut, /usr/localn’est pas considéré comme un dossier "système" par OS X, et sur une nouvelle installation de Snow Leopard, ce dossier est vide.

Tout contenu appartenant à la racine dans ce dossier est le résultat d'un sudo make installautre logiciel ou donne votre mot de passe après un double-clic sur un .pkgfichier qui veut transférer des éléments dans /usr/local.

Owning /usr/locala "travaillé pour moi" sur deux machines pendant plus d'un an.

Un des pièges est que si vous avez installé MySQL (sans utiliser Homebrew) et chown ses fichiers, il ne sera probablement plus en mesure de voir ses bases de données (vous devrez donc les restituer à l'utilisateur sous lequel MySQL est exécuté). .)

Adam Vandenberg
la source
5
gcc et d'autres outils de développement examinent automatiquement le répertoire / usr / local, de sorte que le système en est
affecté
11
Le problème n'est pas que c'est un dossier "système"; c'est qu'il s'agit d'un dossier "global". Même s'il n'y a rien là-bas, /usr/local/binla $PATHvaleur par défaut est toujours présente , et tout ce que vous y mettez peut être utilisé par d'autres utilisateurs aussi et devrait être approuvé . Si tout le /usr/local/répertoire possède les mêmes autorisations que celles /usr/local/share/manactuellement accordées à la configuration de l'OP, n'importe qui peut modifier n'importe quel fichier binaire à l'aide d'un script rm -rf ~.
Samedi
1
trop risqué: il est probable que j'installe MySQL tôt ou tard
Agos
2
@Agos: vous pouvez toujours installer MySQL avec HomeBrew. Dans ce cas, vous n'aurez aucun problème :)
Carmine Paolino
1
@Agos Pas risqué du tout. La mise en garde ne s'applique que si vous avez installé MySQL avant Homebrew. Si vous le faites ensuite, les autorisations sur /usr/localdevraient être correctes. (Mais vous utilisez probablement Postgres de toute façon. :))
Marnen Laibow-Koser le
6

Comme dans Homebrew 1.0.0:

Homebrew n’a plus besoin d’être propriétaire de / usr / local. Si vous le souhaitez, vous pouvez rétablir / usr / local sa propriété par défaut avec: sudo chown root: wheel / usr / local

Yuhao Zhang
la source
1
Je suis en train de mettre à jour Brew en utilisant brew update, qui nécessite toujours la propriété de /usr/local. Je vais essayer de restaurer les autorisations par la suite.
Joshua Pinter
C'est vraiment une bonne information! J'ai défini les permanentes spécifiées par Homebrew (<1.0) et, après la mise à jour, les instructions suivantes ont été données pour les rétablir.
mortona42
0

Je pense qu'il est OK pour les utilisateurs d'avoir les permissions d'écriture à /usr/local- après tout, cela signifie que vous ne l' utilisez sudosur chaque script de compilation. Je n'aime pas l'idée d'un utilisateur ordinaire possédant /usr/local . Je préférerais que root (ou similaire) soit propre /usr/local, mais que je modifie les autorisations pour que les utilisateurs (ou au moins certains groupes privilégiés) puissent y écrire. Cela semble être l'approche conceptuellement correcte.

Marnen Laibow-Koser
la source
7
Le problème ici est qu’il /usr/local/binpeut très bien être à l’avant de $ PATH pour la plupart des utilisateurs. Rendre le répertoire accessible en écriture au monde ouvre de nombreuses failles en matière de sécurité.
nohillside
@patrix Alors changez les chemins. :) Si des scripts présentent des failles de sécurité dues à des chemins de commande ambigus, je les blâmerais et non vos autorisations. Les commandes appelées dans les scripts doivent généralement être entièrement qualifiées pour cette raison. Quoi qu'il en soit, il n'y a pas de meilleure solution: soit vous donnez à votre compte administrateur un umask non sécurisé, soit vous exécutez tous vos scripts de génération avec sudo, ou vous accordez des autorisations d'écriture à certains utilisateurs /usr/local. Je considérerai le troisième comme moins risqué ... à moins que vous ne connaissiez une meilleure solution.
Marnen Laibow-Koser -
Hmm. En y réfléchissant un peu plus, une meilleure solution serait peut-être que Homebrew fasse ce que RVM fait par défaut: installer tout ~/brewou partie. Le problème, cependant, est que, contrairement à Ruby, qui est assez autonome, de nombreux utilitaires * nix s'attendent à se trouver /usr/local...
Marnen Laibow-Koser
3
J'ai négligé de mentionner que mon nom /usr/localn’est pas accessible en écriture: j’ai plutôt un groupe de confiance homebrew(pas seulement un administrateur) doté d’autorisations en écriture (autorisations étendues telles que 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherittotalement rock). C’est le meilleur compromis que j’ai pu comprendre: pas sudode scripts de construction, mais un certain contrôle /usr/local.
Marnen Laibow-Koser -
@ MarnenLaibow-Koser J'aimerais une explication plus détaillée de cette approche (création d'un groupe d'utilisateurs de confiance avec des autorisations d'écriture /usr/local). Faire beaucoup de chalutage sur SO et d'autres sites, voir les arguments concernant le déplacement de Homebrew dans le dossier de départ de l'utilisateur plutôt que de rester dans /usr/local, changer de propriétaire et / ou de groupe /usr/localou non, etc., il est difficile de dire s'il y en a. solution universellement acceptable. Avez-vous un article de blog ou un article à ce sujet, ou pourriez-vous donner une explication plus profonde quelque part?
Gabriel L.