我对/ usr / local /的权限正确吗？

88

我正在使用HomeBrew来满足我的端口需求（似乎比MacPorts更加“干净”）。

我可以不使用sudoing 进行安装（很棒），但是man链接步骤似乎需要它（/usr/local/share/man/man3由拥有root）。我发现
的指南建议我chown /usr/local通过递归

sudo chown -R `whoami` /usr/local

这是安全的吗？还是“坏主意”？

另外：我的权限是否正确？

$ 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 
— 阿戈斯
source
5
这就是使用Homebrew的方式。有些人可能会不同意，但首席开发人员表示要这样做。
— Mike McQuaid 2010年
1
比您的chown好一点的替代方法：sudo chown -R :admin /usr/local。这样，该机器的任何管理员用户都可以使用。尽管您可能还需要运行sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+以确保组具有与用户相同的写访问权限。
— Slipp D. Thompson 2014年
12
“我将使用自制软件，它感觉比macports干净。哦，看看这个定义不明确的权限混乱。我将检查Stack Overflow。哦，这是一个与Unix最佳实践和操作系统更新尝试不符的快速技巧。执行。完美！”。一个月后：“嘿，该恶意软件是如何安装的？”
— hmijail
我使用这种方法的问题是，这意味着只有安装Homebrew的用户帐户才能使用它。我有一台带有多个帐户的Mac，用于将工作项目与家庭项目分开（例如）。如果我登录了错误的帐户，则无法使用brew install。我采取了这种方法来避免使用root的危险，但是我不相信这是最好的方法。
— 吉士甲'17
@MikeMcQuaid我发现有趣的是，Homebrew最终承认了这一错误，并且在一两周前发布的新版本中，已将默认权限恢复为/ usr / local
— oemb1905

Answers:

37

通常最好保持权限尽可能严格。保持/usr/local所有权是root指只有以root/ 运行的进程sudo（或通过Apple授权对话框询问管理员用户）可以写入此区域。因此，进程下载必须在损坏文件之前要求您输入密码。

但是正如您所说，这使添加新程序变得更加困难。

我可以运行sudo，因为您安装东西的频率要低于运行它们的频率，但是您必须相信构建过程不会更改任何应有的内容。

如果您想避免使用sudo，我会在其中安装Homebrew ~/usr/local并更改您的路径，manpath等，以在其中包含目录。

更好的方法是创建另一个用户，例如homebrew创建该用户拥有的目录。然后，使用安装sudo -U homebrew。其他用户将具有无法覆盖任何其他文件的优势，因为它们未按照运行，root 并且其他程序无法影响自制程序。（我注意到，如果您在“多用户环境”中，“ 自制”常见问题解答确实会建议该新用户。我想说，包括macOS在内的任何Unix计算机都是多用户环境）

但是，正如Homebrew Wiki所说，这些食谱并未找到所有情况，而是/usr/local将其替换为所选的目录，我怀疑我们对此感到困惑/usr/local。

— 用户名
source
1
+1用于保持授权严格，并更改$PATH和$MANPATH包括用户目录。如果已安装的程序不需要系统范围的安装，那么它是一个更好的选择。
— zneak 2010年
3
+1并接受“保持尽可能严格的权限”的答案。做brew doctor（建议如下）告诉我，我只需要整理共享的人目录...对我来说足够安全。
— Agos 2010年
1
一个折衷的解决方案是更改组所有权和权限，以便至少管理员可以写入/ usr / local，这至少对于那些关心安全性而又不能始终以Admin用户身份运行的人而言。请参阅kenorb的答案。
— hmijail '16
2
@Mark我发现有趣的是，Homebrew最终承认了这一错误，并且在一两周前发布的新版本中，已将默认权限恢复为/ usr / local
— oemb1905
48

我也使用Homebrew，可以确认它完全安全。引用官方Homebrew常见问题解答上的“ 安装”页面：

帮个忙，挑一个 /usr/local

  1. 更容易
    /usr/local/bin了PATH。

  2. 它更容易
    构建脚本吨打破，如果他们的依赖是不是在任何的/ usr或/ usr /本地。我们为Homebrew公式修复了此问题（尽管我们并不总是对其进行测试），但是您会发现许多RubyGems和Python安装脚本都中断了，这是我们无法控制的。

  3. Apple符合POSIX 的要求是安全的
    ，并将此目录留给了我们。这意味着/usr/local默认情况下没有目录，因此无需担心将现有工具弄乱。

如果您打算安装依赖于酿造的宝石，那么可以省去一堆麻烦并安装到/usr/local！

告诉gem在非标准目录中查找标头和dylib并非易事。如果您选择/usr/local，则所有内容“都将正常运行！”

我只是补充说，以root身份做事是一个非常糟糕的主意，因此chowning /usr/local不仅对我来说似乎很合理（这不是OSX上的系统目录），而且理智。

您的权限不正确（尚未）。只需运行您列出的命令，就可以了。

如果您还有其他问题，请记住，brew doctor可以为您提供帮助！

— 胭脂红Paolino
source
评论不作进一步讨论；此对话已转移至聊天。
— bmike
7
聊天不见了，真可惜。因此，冒着重复历史的风险，我将在这里留下我的评论：这样做并不意味着这样做是安全的。
— hmijail
4
图表的要点是，尽管这是Homebrew所建议的，但有一些原因可以解释为什么这是错误的
— user151019
1
brew doctor简直太棒了。
— Utku'9
5
@Carmine Paolino我发现有趣的是，Homebrew最终承认了这一错误，在一两个星期前发布的新版本中，已将默认权限恢复为/ 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以解决问题。

— Kenorb
source
+1可以提供一个实际的，表现良好的解决方案，即使尚未真正完成。例如：将用户添加到BSD级别的管理员组？这不会与OS X的Admin用户的概念混淆吗？
— hmijail
作为记录，我遵循了这些说明，但是仅使用了现有的OS X GUI管理员用户身份，而不是将任何人添加到CLI中的任何组中。它的工作原理是：为了能够运行brew命令，我必须先执行su myAdminUser，然后一切都按预期进行。但是，当然，对于一直一直在运行Admin用户的用户来说，此解决方案将不会提供任何安全性。
— hmijail '16
这可能是最好的方法，我同意@kenorb
— pixel
7

就其价值而言，/usr/localOS X不会将其视为“系统”文件夹，而在全新的Snow Leopard上，该文件夹为空。

该文件夹中所有由root拥有的东西都是由于sudo make install其他软件引起的，或者是双击.pkg想要将东西转储到的，然后提供了密码/usr/local。

Owning /usr/local在2台计算机上为我“工作”了一年多。

一个陷阱是，如果您已经安装了MySQL（未使用Homebrew）并销毁了它的文件，那么它可能将不再能够查看其数据库（因此，您必须将它们销还给MySQL正在运行的任何用户。 ）

— 亚当·范登堡（Adam Vandenberg）
source
5
gcc和其他开发工具的确会自动在/ usr / local中查找，因此会影响系统
— user151019 2010年
11
问题不在于它是一个“系统”文件夹；而是 这是一个“系统范围”的文件夹。即使那里什么也没有，/usr/local/bin仍然是默认$PATH值，您在其中输入的任何内容也可以被其他用户使用，并且应该被信任。如果整个/usr/local/目录/usr/local/share/man当前具有与OP设置相同的权限，则任何人都可以使用脚本来更改任何二进制文件rm -rf ~。
— zneak 2010年
1
风险太大：我迟早会安装MySQL
— Agos 2010年
2
@Agos：您始终可以使用HomeBrew安装MySQL，在这种情况下，您不会有任何问题:)
— Carmine Paolino 2010年
1
@Agos一点都不冒险。仅当您在Homebrew之前安装MySQL时，才适用此警告。如果您以后再做，则对它的权限/usr/local应该很好。（但你可能使用的Postgres反正:)）
— Marnen Laibow-科泽
6

如Homebrew 1.0.0中所示：

自制程序不再需要拥有/ usr / local的所有权。如果愿意，可以使用以下命令将/ usr / local返回其默认所有权：sudo chown root：wheel / usr / local

— 张玉浩
source
1
我目前正在使用来更新Brew brew update，但仍然需要的所有权/usr/local。之后，我将尝试恢复权限。
— 约书亚·品特
这真的是很棒的信息！我设置了Homebrew（<1.0）指定的权限，更新后，它给出了有关如何重新设置权限的这些说明。
— mortona42年
0

我认为用户具有写权限是可以的/usr/local-毕竟，这意味着您不会sudo在每个构建脚本上使用。我不喜欢普通用户拥有 的想法/usr/local。我希望拥有root（或类似的）拥有/usr/local权限，但更改权限，以便用户（或至少某些特权组）可以写入该权限。这似乎是概念上正确的方法。

— 玛嫩·莱伯·科瑟
source
7
/usr/local/bin对于大多数用户而言，这里的问题很可能位于$ PATH的前面。使目录可写入世界将以这种方式打开许多安全漏洞。
— nohillside
@patrix所以改变路径。:)如果您的脚本由于命令路径不明确而存在安全漏洞，我会怪罪脚本，而不是您的权限-正是出于这个原因，脚本中调用的命令通常应该完全合格。无论如何，没有更好的解决方案：您给管理员帐户一个不安全的umask，或者使用来运行所有构建脚本sudo，或者给某些用户授予的写入权限/usr/local。我认为第三者风险最小...除非您知道更好的方法。
— Marnen Laibow-Koser
嗯 再多考虑一下，也许更好的方法是让Homebrew默认执行RVM的工作：将所有内容安装到其中~/brew或类似的东西中。不过，问题在于，与Ruby完全独立的不同，许多* nix实用程序希望在/usr/local...中找到对方
— Marnen Laibow-Koser 2013年
3
我忽略了我/usr/local不是世界可写的问题：相反，我有一个受信任的组homebrew（不仅仅是管理员），该组对此具有写权限（扩展权限，例如0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherit完全摇滚）。这是最好的折衷办法我已经能够搞清楚：没有sudo上生成脚本，但一些控制/usr/local。
— Marnen Laibow-Koser
@ MarnenLaibow-Koser我希望看到这种方法的更深入的说明（创建对拥有写权限的受信任用户组/usr/local）。在SO和其他站点上进行了大量的拖网捕捞，看到的论据是：将Homebrew移到用户的home文件夹中与保留/usr/local，更改所有者和/或组的所有者/usr/local等等，等等……很难判断是否存在任何普遍接受的解决方案。您是否有关于此的博客文章或文章，或者您能在某处给出更深入的解释吗？
— 加布里埃尔·L.
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.