/ usr / local /の許可は正しいですか?


88

私はポートのニーズにHomeBrewを使用しています(MacPortsよりも少し「きれい」に見えます)。

私はsudoing なしでインストールできます(これは素晴らしいです)が、manリンクのステップではそれが必要なようです(/usr/local/share/man/man3が所有していますroot)。私が見つけ
ガイドは、私が再帰的chown /usr/local

sudo chown -R `whoami` /usr/local

これは安全ですか?それともBad Idea™ですか?

また、私の許可は正しいですか?

$ 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

5
これがHomebrewの使用方法です。一部の人々は同意しないかもしれませんが、リード開発者はそうするように言っています。
マイクマッケイド

1
あなたのchownのわずかに優れた代替品:sudo chown -R :admin /usr/local。この方法では、マシンの管理ユーザーに対して同じように機能します。ただしsudo find /usr/local -perm -200 -exec chmod g+w '{}' \+、グループにユーザーと同じ書き込みアクセス権があることを確認するために実行する必要がある場合もあります。
スリップD.トンプソン14年

12
「homebrewを使用します。macportsよりもすっきりしています。ああ、この不明確な許可の混乱を見てください。StackOverflowで確認します。ああ、ここにUnixのベストプラクティスとOSアップデートの試みに反する簡単なハックがあります。強制する。完璧!」。1か月後:「ねえ、このマルウェアはどのようにインストールされたのですか?」
hmijail

私がこのアプローチで抱えている問題は、Homebrewをインストールするユーザーアカウントのみがそれを使用できることを意味することです。複数のアカウントを持つMacがあり、これを使用して、仕事用プロジェクトを自宅用プロジェクトから分離します(たとえば)。間違ったアカウントにログインしている場合、brew installを使用できません。ルートを使用する危険を回避するためにこのルートを取りましたが、それが最良のアプローチであるとは確信していません。
オースピス

@MikeMcQuaid Homebrewが最終的にこの問題を認め、1、2週間前にリリースされた新しいバージョンで、デフォルトのアクセス許可を/ usr / localに復元したことを興味深いと思います
-oemb1905

回答:


37

通常、許可はできるだけ厳しくすることをお勧めします。/usr/local所有権を保持するrootということは、root/ として実行されるプロセスsudo(またはApple認証ダイアログボックスで管理者ユーザーに要求するプロセス)のみがこの領域に書き込みできることを意味します。したがって、プロセスのダウンロードでは、ファイルを破損する前にパスワードを要求する必要があります。

しかし、あなたが言うように、それは新しいプログラムの追加をより難しくします。

私が実行しているとOKだsudoあなたが少なく、多くの場合、それらを実行するよりも、物事をインストールすると、しかし、あなたは、ビルドプロセスは、それが必要何も変更しないことを信頼しなければなりません。

sudoを避けたい場合は、Homebrewをインストールし~/usr/local、パス、マンパスなどを変更して、その下のディレクトリを含めます。

より良い方法は、別のユーザーを作成homebrewすることです。たとえば、そのユーザーが所有するディレクトリを作成します。次に、を使用してそこにインストールしsudo -U homebrewます。他のユーザーは、他のファイルを上書きできないという利点があります。他のユーザーは実行されておらずroot 、他のプログラムがhomebrewに影響を与えないためです。(Homebrew FAQは、「マルチユーザー環境」にいる場合、この新しいユーザーを提案していることに注意してください。macOSを含むUnixマシンはマルチユーザー環境であると言えます)

しかし、Homebrew wikiは、レシピがすべてのケースを見つけ/usr/localて、選択したディレクトリに置き換えるわけではないと言っているので、私たちは行き詰まっていると思い/usr/localます。


1
承認を厳格に保ち、ユーザーディレクトリを変更$PATH$MANPATHて含めるために+1 。インストールされたプログラムがシステム全体のインストールを必要としない場合は、はるかに優れた代替手段です。
zneak

3
「許可を可能な限り厳しく保つ」ための+1と受け入れられた回答。brew doctor(以下に推奨)を行うと、共有されたmanディレクトリのみをチャネリングする必要があると私に言われました...私にとって十分に安全です。
アゴス

1
少なくとも管理者ユーザーとして常に実行されないほどのセキュリティを必要とする人にとっては、グループの所有権とアクセス許可を変更して、管理者だけが/ usr / localに書き込みできるようにすることです。kenorbの答えをご覧ください。
hmijail

2
@Mark Homebrewがこれについに過失を認め、1、2週間前にリリースされた新しいバージョンで、/ usr / localにデフォルトのアクセス許可を復元したことを興味深いと思います
-oemb1905

48

私もHomebrewを使用しており、完全に安全であることを確認できます。公式Homebrew FAQインストールページを引用:

自分で好意的に選んでください /usr/local

  1. 簡単になっ
    /usr/local/binていますPATH


  2. 依存関係が/ usrまたは/ usr / localにない場合、多くのビルドスクリプトが壊れやすくなります。Homebrewの式ではこれを修正します(常にテストするわけではありません)が、多くのRubyGemsおよびPythonセットアップスクリプトが壊れていることがわかります。

  3. AppleがPOSIXに準拠し、このディレクトリを残してくれたのは安全
    です。つまり/usr/local、デフォルトではディレクトリがないため、既存のツールを台無しにする心配はありません。

醸造に依存するgemをインストールする場合は、手間を省いてインストールして/usr/localください!

gemに非標準のディレクトリでヘッダーとdylibを探すよう指示するのは簡単ではありません。を選択すると/usr/local、すべてが「正常に動作します!」

ルートとして物事行うことは非常に悪い考えだと付け加えます。そのため、chowning /usr/localは私にとって理にかなっているように見えるだけでなく(OSXのシステムディレクトリではありません)、正気です。

あなたの許可は(まだ)正しくありません。リストしたコマンドを実行するだけで大​​丈夫です。

他に問題がある場合は覚えておいbrew doctorてください。


コメントは詳細なディスカッション用ではありません。この会話はチャットに移動さました
bmike

7
チャットはなくなりましたが、残念です。したがって、履歴を繰り返すリスクを冒して、ここにコメントを残しておきます。これが行われたからといって、これが安全であるという意味ではありません。
hmijail

4
グラフの要点は、これがHomebrewが示唆していることですが、これが間違っている理由には理由があるということです
-user151019

1
brew doctor単に素晴らしいです。
Utku

5
@Carmine Paolino Homebrewがついにこれに誤りを認め、1、2週間前にリリースされた新しいバージョンで、デフォルトのアクセス権を/ usr / localに復元したことを興味深いと思います
-oemb1905

9

Homebrewを使用している場合は、特定のグループ(adminまたはstaff)に書き込み許可を与える必要があります。これにより、そのグループ内のユーザー間でファイルを共有できます。

例えば:

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

次に、brewコマンドにアクセスする必要があるユーザーをそのグループに割り当てます(グループを次の方法で確認しますid -Gn)。

で作業するときはbrew、で実行しないでくださいsudo

まだ許可の問題がある場合は、実行brew doctorして問題のトラブルシューティングを行います。


+1は、たとえ実際に終了していなくても、実際のより良い振る舞いのソリューションを提供したことに対して。たとえば、BSDレベルで管理グループにユーザーを追加しますか?これは、OS Xの管理者ユーザーの概念を混乱させませんか?
hmijail

記録のために、私はこれらの指示に従いましたが、CLIのグループに誰かを追加する代わりに、既存のOS X GUIで作成されたAdminユーザーを使用しました。動作します:brewコマンドを実行するには、最初にを実行する必要su myAdminUserがあり、次にすべてが意図したとおりに動作します。しかし、もちろんこのソリューションは、とにかくすでに管理者ユーザーを実行している人々にセキュリティを提供しません。
hmijail

これがおそらく最善の方法です。@ kenorbに同意します
ピクセル67

7

価値のあるもの/usr/localは、OS Xによって「システム」フォルダーとは見なされず、新しいSnow Leopardのインストールでは、そのフォルダーは空です。

そのフォルダ内のルート所有のものは、sudo make install他のソフトウェアの結果、または.pkgものをダンプしたいものをダブルクリックした後にパスワードを与えた結果です/usr/local

所有/usr/localは1年以上2台のマシンで「私のために働きました」。

1つの落とし穴は、MySQLをインストールして(Homebrewを使用していない)、そのファイルをchownすると、おそらくそのデータベースをもう見ることができないことです(したがって、MySQLを実行しているユーザーに戻す必要があります) )


5
gccおよびその他の開発ツールは/ usr / localを自動的に検索するため、システムに影響します
user151019

11
問題は、それが「システム」フォルダーであるということではありません。それが「システム全体」のフォルダーであるということです。そこに何もない場合/usr/local/binでも、デフォルト$PATH値のままであり、そこに置いたものはすべて他のユーザーも使用でき、信頼できるはずです。/usr/local/ディレクトリ全体が/usr/local/share/man現在OPのセットアップと同じアクセス許可を持っている場合、誰でもスクリプトを使用して任意のバイナリを変更できますrm -rf ~
zneak

1
危険すぎる:それは私は遅かれ早かれMySQLをインストールすることを可能性があります
AGOS

2
@Agos:HomeBrewでMySQLをいつでもインストールできます。この場合、問題はありません:)
カーマイン

1
@Agosまったく危険ではありません。注意は、Homebrewの前にMySQLをインストールした場合にのみ適用されます。後でそれを行う場合、アクセス許可は問題/usr/localないはずです。(ただし、おそらくとにかくPostgresを使用します。:))
Marnen Laibow-Koser 14

6

Homebrew 1.0.0の場合:

Homebrewは/ usr / localの所有権を持つ必要がなくなりました。必要に応じて、次のコマンドで/ usr / localをデフォルトの所有権に戻すことができます。sudo chown root:wheel / usr / local


1
現在brew update、を使用してBrewを更新していますが、まだ所有権が必要です/usr/local。後で権限を復元してみます。
ジョシュアピンター

これは本当に素晴らしい情報です!Homebrew(<1.0)で指定されたとおりにパーマを設定し、更新後、これらのパーマを設定する方法を説明しました。
mortona42

0

私は、ユーザーが持っているため、それはOKだと思う書き込み権限を/usr/localた後に、すべてのあなたが使用していないことを意味し、 - sudoすべてのビルドスクリプトに。私は普通のユーザーが所有する という考えは好きではありません/usr/local。root(または同様の)ownを持ちたいのです/usr/localが、ユーザー(または少なくともいくつかの特権グループ)が書き込みできるようにパーミッションを変更します。それは概念的に正しいアプローチのようです。


7
ここでの問題は、/usr/local/binほとんどのユーザーにとって$ PATHの先頭にある可能性が非常に高いことです。ディレクトリを誰でも書き込み可能にすると、多くのセキュリティホールがそのように開きます。
nohillside

@patrixしたがって、パスを変更します。:)コマンドパスがあいまいなためにセキュリティホールのあるスクリプトがある場合は、権限ではなくスクリプトを非難します。通常、スクリプトで呼び出されるコマンドは、まさにこの理由で完全に修飾される必要があります。とにかく、より良い解決策はありません:adminアカウントに安全でないumask sudoを与えるか、すべてのビルドスクリプトをで実行するか、一部のユーザーにに対する書き込み権限を与えます/usr/local。3番目の方法は、リスクが最も低いと考えます...より良い方法を知っている場合を除きます。
マルネンライボウコーザー

うーん。これについてもう少し考えてみると、HomebrewにRVMがデフォルトで行うことを実行させる方が良いかもしれません~/brew。問題は、しかし、かなり自己完結型であるルビーとは異なり、* nixのユーティリティの多くはでお互いを見つけることを期待ということです/usr/local...
Marnen Laibow-Koser

3
/usr/localは自分が誰でもhomebrew書き込めないことを忘れていました。むしろ、書き込み権限(0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherit完全なロックなどの拡張権限)を持つ信頼できるグループ(管理者だけでなく)がいます。これは、私が理解できた最高の妥協案です。sudoビルドスクリプトはありませんが、をある程度制御でき/usr/localます。
マーネンライボウコーザー

@ MarnenLaibow-Koserこのアプローチのより詳細な説明(書き込み権限を持つユーザーの信頼できるグループの作成/usr/local)が見たいです。SOや他のサイトで多くのトロールを行い、引数を確認します:Homebrewをユーザーのホームフォルダーに移動するか、保持するか/usr/local、所有者やグループを変更するかどうかなど/usr/local...があるかどうかを判断するのは困難です広く受け入れられるソリューション。これについてのブログ記事や記事はありますか、それともどこかに詳しい説明がありますか?
ガブリエルL.
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.