題:
我對/ usr / local /的權限正確嗎？
Agos
2010-09-10 15:07:37 UTC
view on stackexchange narkive permalink

我正在使用 HomeBrew來滿足我的端口需求（似乎比MacPorts更加“乾淨”）。

我可以在沒有 sudo 的情況下安裝（很棒），但是man鏈接步驟似乎需要它（ / usr / local / share / man / man3 由 root 擁有。
指南我發現建議我通過遞歸 chown / usr / local > 

  sudo chown -R`whoami` / usr / local

這是安全的嗎？或者它是Bad Idea™嗎？

還：我的權限是否正確？

  $ pwd / usr / local / share / man $ ls -lahtotal 32drwxrwxr-x 8根桿272B 4設置11:02 .drwxrwxr-x 9根桿306B 10設置11:27 ..drwxr-xr-x 3根輪102 A 4 2009年前dedrwxrwxr-x 163根桿5,4K 10設置11:27 man1drwxr-xr-x 11根輪374B 10設置11:27 man3drwxr-xr- x 7以前職員238B 10組11:39 man5drwxr-xr-x 11以前職員374B 10組11:39 man7-rw-r--r-- 1個根職員13K 4組11:02 whatis
這就是使用Homebrew的方式。有些人可能會不同意，但是首席開發人員表示要這樣做。
代替chown的更好的替代品：sudo chown -R：admin / usr / local。這樣，該機器的任何管理員用戶都可以使用。儘管您可能還需要運行`sudo find / usr / local -perm -200 -exec chmod g + w'{}'\ +`以確保該組具有與用戶相同的寫訪問權限。
“我將使用自製軟件，感覺比macports乾淨。哦，看看這個定義不明確的權限混亂。我將檢查Stack Overflow。哦，這是一個快速的技巧，違背了Unix最佳實踐和嘗試的OS更新執行。完美！”。一個月後：“嘿，該惡意軟件是如何安裝的？”
我使用這種方法的問題是，這意味著只有安裝Homebrew的用戶帳戶才能使用它。我有一台具有多個帳戶的Mac，用於將工作項目與家庭項目分開（例如）。如果我登錄了錯誤的帳戶，則無法使用brew install。我採取了這種方法來避免使用root的危險，但是我不相信這是最好的方法。
@MikeMcQuaid我發現有趣的是，Homebrew最終承認了這一錯誤，並且在一兩週前發布的新版本中，已將默認權限恢復為/ usr / local
@Agos參見上面的評論
七 答案:
Carmine Paolino
2010-09-10 15:47:29 UTC
view on stackexchange narkive permalink

我也使用自製軟件，可以確認它完全安全。引用官方自製軟件常見問題解答上的安裝頁：

幫個忙，選擇 / usr / local

  1. 更容易
    / usr / local / bin 已在您的 PATH 中>。

  2. 更容易
    如果依賴項不在/ usr或/ usr / local中，則會破壞大量構建腳本。我們為Homebrew公式修復了此問題（儘管我們並不總是對其進行測試），但是您會發現許多RubyGems和Python安裝腳本都中斷了，這超出了我們的控制範圍。

  3. 這很安全
    Apple已遵循POSIX的規定，並把這個目錄留給了我們。這意味著默認情況下沒有 / usr / local 目錄，因此無需擔心會弄亂現有工具。
    4. ol>

    計劃安裝依賴於釀造的寶石，然後為自己省去一堆麻煩並安裝到 / usr / local ！

    告訴寶石非標準外觀並非易事標頭和dylib的目錄。如果選擇 / usr / local ，則所有內容都“正常工作”！

我只是添加以root身份執行操作是一個非常糟糕的主意，因此 chown / usr / local 不僅對我來說很合理（它不是OSX上的系統目錄），而且理智 >。

您的權限不正確（尚未）。只需運行列出的命令，就可以了。

如果您還有其他問題，請記住
brew doctor 可以為您提供幫助！

評論不作進一步討論；此對話已[移至聊天]（http://chat.stackexchange.com/rooms/31567/discussion-on-answer-by-carmine-paolino-are-my-permissions-for-usr-local-corre）。
聊天不見了，真可惜。因此，冒著重複歷史的風險，我將在這裡留下我的評論：這樣做並不意味著這樣做是安全的。
圖表的要旨是，儘管這是Homebrew所建議的，但仍有一定理由說明這是錯誤的
“釀酒醫生”簡直太棒了。
@Carmine Paolino我發現有趣的是，Homebrew最終承認了這一錯誤，並且在一兩週前發布的新版本中，已將默認權限恢復為/ usr / local
mmmmmm
2010-09-10 15:50:57 UTC
view on stackexchange narkive permalink

通常最好保持權限盡可能嚴格。將 / usr / local 保留為 root 的所有權意味著僅以 root / sudo 運行的進程（或要求管理員用戶（通過Apple授權對話框）可以寫入此區域。因此，進程下載必須在破壞那裡的文件之前要求您輸入密碼。

但是正如您所說，這會使添加新程序變得更加困難。

我可以運行 sudo ，因為您安裝它們的頻率要比運行它們的頻率低，但是您必須相信構建過程不會對它進行任何更改。

如果要避免使用sudo，我會將Homebrew安裝到〜/ usr / local 並更改您的路徑，manpath等，以在其中包含目錄。

更好的方法是創建另一個用戶，例如 homebrew 並創建該用戶擁有的目錄。然後，使用 sudo -U homebrew 安裝在那裡。其他用戶將具有無法覆蓋任何其他文件的優勢，因為它們沒有以 root 身份運行，並且其他程序不會影響自製程序。 （我注意到，如果您處於“多用戶環境”中， Homebrew FAQ確實會建議該新用戶。我想說，包括macOS的任何Unix計算機都是多用戶環境）

p>但是正如Homebrew Wiki所說的那樣，食譜並沒有找到所有 / usr / local 的情況，而是將它們替換為選定的目錄，我懷疑我們被困在 / usr / local 代碼>。
+1用於保持授權嚴格，並更改`$ PATH`和`$ MANPATH`以包括用戶目錄。如果已安裝的程序不需要係統範圍的安裝，那麼它是一個更好的選擇。
+1並接受“保持盡可能嚴格的權限”的答案。做“釀酒醫生”（建議如下）告訴我，我只需要穿插共享目錄，對我來說足夠安全。
一個折衷的解決方案是更改組所有權和權限，以便至少管理員可以寫入/ usr / local，這至少對於那些關心安全性而又不能始終以Admin用戶身份運行的人而言。請參閱kenorb的答案。
@Mark我發現有趣的是，Homebrew最終承認了這一錯誤，並且在一兩週前發布的新版本中，已將默認權限恢復為/ usr / local
kenorb
2015-05-30 15:09:19 UTC
view on stackexchange narkive permalink

如果您使用的是Homebrew，則應將寫入權限授予特定的組（ admin 或 staff ），以便可以在以下用戶之間共享文件：

例如：

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

然後將應該有權使用 brew 命令的用戶分配給該組（通過以下方法檢查您的組： id -Gn ）。

然後，當使用 brew 進行操作時，請勿使用 sudo 來運行它。

如果仍有一些權限問題，請運行 brew醫生來解決問題。

+1可以提供一個實際的，表現良好的解決方案，即使尚未真正完成。例如：將用戶添加到BSD級別的管理員組？這不會與OS X的Admin用戶的概念混淆嗎？
作為記錄，我遵循了這些說明，但是僅使用了現有的OS X GUI管理員用戶身份，而不是將任何人添加到CLI中的任何組。它的工作原理是：為了能夠運行brew命令，我必須先執行`su myAdminUser`，然後一切都會按預期進行。但是，當然，對於一直一直在運行Admin用戶的人來說，此解決方案不會提供任何安全性。
我同意@kenorb，這可能是最好的方法
Adam Vandenberg
2010-09-10 20:57:27 UTC
view on stackexchange narkive permalink

就其價值而言，OS X不將 / usr / local 視為“系統”文件夾，並且在全新的Snow Leopard上安裝該文件夾為空。

該文件夾中任何root擁有的東西都是由於其他軟件上的 sudo make install 導致的，或者是雙擊要轉儲的 .pkg 後輸入密碼的結果

擁有 / usr / local 已在兩台計算機上“為我工作”超過一年。

一個陷阱是，如果您已經安裝了MySQL（不使用Homebrew）並整理了其文件，那麼它可能將不再能夠查看其數據庫（因此您必須將其整理給任何用戶MySQL正在運行。）

gcc和其他開發工具會自動在/ usr / local中查找，因此會影響系統
問題不在於它是一個“系統”文件夾；而是這是一個“系統範圍”的文件夾。即使那裡什麼也沒有，`/ usr / local / bin`仍然是默認的$ PATH值，並且您放置在其中的任何內容也可以被其他用戶使用，並且應為_trusted_。如果整個`/ usr / local /`目錄具有當前OP設置中的`/ usr / local / share / man`相同的權限，則任何人都可以使用執行`rm -rf〜`的腳本來更改任何二進製文件。
風險太大：我遲早會安裝MySQL
您可以始終使用@Agos:與HomeBrew一起安裝MySQL，在這種情況下，您不會有任何問題:)
@CarminePaolino不是一個好主意。通常，像MySql這樣的Mac安裝程序，甚至比像Homebrew這樣的非常出色的軟件包管理器，都表現得更好。
@Agos完全沒有風險。僅當您在Homebrew之前安裝MySQL時，才適用此警告。如果事後這樣做，那麼對`/ usr / local`的權限應該沒問題。 （但是您仍然可能使用Postgres。:)）
Yuhao Zhang
2016-09-21 22:55:56 UTC
view on stackexchange narkive permalink

與Homebrew 1.0.0相同：

自製軟件不再需要擁有/ usr / local的所有權。如果你希望 您可以使用以下命令將/ usr / local返回其默認所有權：sudo chown 根目錄：wheel / usr / local

我目前正在使用`brew update`更新Brew，後者仍然需要`/ usr / local`的所有權。之後，我將嘗試恢復權限。
這真的是很棒的信息！我設置了Homebrew（<1.0）指定的權限，更新後，它給出了有關如何重新設置權限的這些說明。
Matias
2020-02-10 02:10:57 UTC
view on stackexchange narkive permalink

從macOS High Sierra或更高版本開始，不再可以編寫 / usr / local 。

Homebrew團隊現在推薦： sudo chown -R $（whoami）$（brew --prefix）/ * 來修復Homebrew權限。

請參閱 @Carmine Paolino的答案，詳細了解為何Homebrew建議取得Homebrew目錄的所有權。

Marnen Laibow-Koser
2013-05-29 21:42:29 UTC
view on stackexchange narkive permalink

我認為用戶對 / usr / local 具有寫權限沒關係-畢竟，這意味著您不使用 sudo 每個構建腳本上的code>。我不喜歡普通用戶擁有 / usr / local 的想法。我希望擁有root（或類似）自己的 / usr / local ，但要更改權限，以便用戶（或至少某些特權組）可以寫入該權限。這似乎是概念上正確的方法。

這裡的問題是對於大多數用戶來說，/ usr / local / bin可能位於$ PATH的最前面。將該目錄設置為可寫入世界後，將打開很多安全漏洞。
-1
嗯再多考慮一下，也許更好的方法是讓Homebrew默認執行RVM的工作：將所有內容安裝到`〜/ brew`或類似的文件中。但是，問題在於，與Ruby完全獨立的不同，許多* nix實用程序希望在`/ usr / local`中找到彼此。
我忽略了我的`/ usr / local`不是世界可寫的：相反，我有一個受信任的組`homebrew`（不僅僅是admin），它對它具有寫權限（擴展權限，如`0：group：自家允許添加文件，刪除，添加子目錄，刪除子項，文件繼承，目錄繼承完全）。這是我能夠找出的最好的折衷方案：構建腳本中沒有`sudo`，但是對/ usr / local有一些控制。
@MarnenLaibow-Koser我希望看到這種方法的更深入的說明（創建一個對`/ usr / local`具有寫權限的受信任用戶組）。在SO和其他站點上進行了大量的拖網捕撈，看到的論據是：將Homebrew移到用戶的主文件夾中，而不是保存在/ usr / local中，是否更改所有者和/或/ usr / local的組，以及等等...很難判斷是否有任何普遍接受的解決方案。您是否有關於此的博客文章或文章，或者可以在某處進行更深入的說明？
@GabrielL。歸結為您是否擁有一個以上的用戶（還有我的答案），如果有的話，哪個用戶應該擁有/ usr / local
@GabrielL。你不明白哪一部分？如果您了解* nix權限是如何工作的，並考慮了誰應該能夠寫入`/ usr / local`，那麼設置應該是不言而喻的。
@MarnenLaibow-Koser-感謝您的回复。不是我不了解，而是我不知道自己不知道的程度。;-)通常，我試圖辨別該方法的潛在弊端/不利之處。這似乎是一個很好的折衷方案。
@GabrielL。自製軟件在常見問題解答中建議這種方式，但適用於“多用戶環境”
@Marnen:我們應該注意，由於Catalina / usr / local是一個牢固的鏈接，因此您無法為其創建ACL。因此，您需要對子目錄執行此操作。我剛剛嘗試過，它可以工作：/ usr / local / bin是root：wheel，但是_brew組的ACL允許訪問。但是，您自己的帳戶也必須是該組的成員。然後，以用戶身份運行的每個進程仍然可以在沒有root特權的情況下寫入這些子目錄。我們需要一種使其*不*將您自己的用戶添加到該組的方法。有沒有一種方法可以將您的用戶切換到不屬於該用戶的組？
否……請問最後一個問題：如果將用戶添加到_brew組，您仍將保留在人員（20）中。然後“ brew doctor”會告訴您/ usr / local / bin是不可寫的。如果您使用“ newgrp brew”切換到_brew組，那麼“ brew doctor”將不會標記/ usr / local / bin。因此，這實際上是一個相當不錯的解決方案。
PS不，似乎只在原始Terminall會話中起作用。重新登錄後，_brew組被接受，501和_brew被“結婚”，並且您無需更改組即可寫入/ usr / local / bin…，因此這種方法不會增加安全性。因此，最初的問題仍然存在：是否可以將用戶切換到不是其成員的組？
@JayB您可以將用戶添加到您喜歡的任何組中。


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 2.0許可。
Loading...