我知道这/usr/local是为了什么-为本地计算机安装软件。默认情况下，root拥有目录。这意味着要在此处安装，您需要使用sudo。对于单用户或开发人员的计算机，这似乎是不必要的命令额外使用。因此，我的问题是-拥有自己的财产安全/usr/local吗？
例如，用于OS X“ Just Works”的Homebrew，因为他们在不使用的情况下拥有/usr/local并安全地在其中安装了软件sudo。
此外，如果您已将本地编译的软件安装到/usr/local，则该软件当前需要root才能自行修改或安装插件。这似乎是不安全的-我想只使用sudo，当我知道确切地会发生什么。
意见？
Answers:
我不建议成为/usr/local; 的所有者。在大多数情况下，它的安全性可能不如使用sudo。
您的问题提出了您可能想要的两个原因chown /usr/local。
首先是避免必须使用sudo安装软件。这可能使某些人（例如，该答案的作者）读到您想有效地工作，或者保存键入sudo和输入密码所需的击键。但是可能当您说“不必要”时，是指最小特权原则：
默认情况下，
root拥有目录。这意味着要在此处安装，您需要使用sudo。对于单用户或开发人员的计算机，这似乎是不必要的命令额外使用
我经常听到/读过与“我是唯一使用此系统的人，因此我不需要使用sudo和输入密码”的观点。对于具有这种观点的读者，因为它与此处有关，因此让我们提醒自己，root拥有事物的基本安全原因。
在Ubuntu系统上安装的大多数程序文件的文件模式为755或符号表示rwxr-xr-x，这意味着任何用户或程序都可以执行它们，但是只有文件所有者root才能修改它们。（从技术上讲，这还要求除root以外，没有人w对包含它们的目录具有权限，因此其他用户不能删除或移动它们。）
这意味着您（谦虚的用户）可以执行任何程序。如果您尝试使用程序来执行您无权执行的操作，例如对root拥有的文件执行写操作，它将出错。这使得某些命令，错误的应用程序或恶意代码中的错别字不太可能破坏您的系统-除非它以root身份运行，否则将无权这样做。当运行与Internet交互的程序时，这特别有用。
如果您具有特权chown /usr/local，则任何运行该程序的程序都可以在其中写入文件，由于某些原因，该文件以后可能会以root用户身份执行，例如，通过替换另一个同名命令。/usr/local/bin在默认情况下$PATH，在sudo的secure_path，并谈到前两个其他位置。所以如果我有两个可执行文件
/usr/local/bin/chown
/bin/chown
当我执行sudo chown ...，将chown在/usr/local/bin将被执行。
但是您可能已经知道了这一切，因为您的第二个原因是关于安全性的：
此外，如果您已将本地编译的软件安装到
/usr/local，则该软件当前需要root才能自行修改或安装插件。这似乎是不安全的-我想只使用sudo，当我知道确切地会发生什么。
万一有必要在此提及，将本地编译的软件安装到绝对是正确的（无论如何，根据FHS）/usr/local，但是编译本身应该在您的某处完成$HOME，而无需进行sudo，直到键入sudo make install或等效命令的最后一步为止。
我认为您建议通过/usr/local以无特权的所有者身份运行安装的程序，可以使用在尝试更新自身时看到的特定权限错误，以查看它试图以某种方式修改您不拥有的其他文件系统位置不需要，这样您就可以阻止它这样做。
这可能会有所帮助。这意味着您相信程序可以在/usr/local而不是其他地方执行它喜欢的任何事情。如果它要求提升的权限，则可以拒绝允许它更新或卸载它。这对我来说很有意义。但是我认为尝试以/usr/local这种方式用作沙盒可能不是一个好主意，或者至少它不太可能是最安全的解决方案。它不是一个适当隔离的位置（/opt因为它不在默认位置，所以隔离度更高一些$PATH）。该程序可能会在其中写入或删除内容，/usr/local从而造成伤害。您运行的其他（可能写得不好）程序可能会在您不知道的地方编写和执行代码。
如果您担心允许程序安全地自我更新，则可能应该寻找替代方案（例如，特定于该程序，例如python，或者可以寻找适合您需要的快照或类似实现，或者使用容器或VM，以测试可能不安全的软件），然后再公开要由普通用户运行的程序写入的系统位置（甚至是相对用户相对）。在我看来，如允许程序使用临时提升权限，可能会产生不可预测的影响sudo。
/usr/local不属于的情况很罕见root。但是您可以根据需要更改所有者。
但是我建议确保/usr/local/sbin仍归所有者所有，root以避免出现安全问题。通常仅由root调用此处的命令。
/usr/local/bin那么该根命令（以及其他用户）中的命令又会如何运行？他们不是必须由root拥有吗？此外，root用户使用的命令（包括中的命令）/usr/local/sbin可能取决于中的共享库/usr/local/lib。更改这些库可以对使用它们的命令的行为进行任意更改。坚持只/usr/local/sbin保留root所有权似乎是完全任意的。
/usr/local。无需更改所有权/usr/local或在不需要时不必以root用户身份运行命令，您只需配置构建，使其安装在主目录中即可/usr/local。这解决了更改所有权的所有潜在问题/usr/local，包括其bin和sbin子目录root的路径。
如果确实需要允许其他用户运行您的软件，则可以授予他们访问权限。实际上，它们可能已经可以了，因为默认情况下，您的主目录具有允许的读取和执行访问权限。（如果您不希望这样做，则可以很容易地对其进行更改，只需使用chmod要私有化的任何文件或目录，还可以更改您的umask。）
在主目录中安装了软件之后，本应进入的二进制文件/usr/local/bin将进入。您将获得主目录的其他子目录，这些子目录与您安装的软件所需的子目录相对应。当您从源代码安装软件时，这通常会自动发生。/home/username/bin/usr/local
您从源代码构建的大多数软件都有一个运行步骤：
./configure对于大多数带有configure可像这样运行的脚本的软件，默认情况下，/usr/local当最终运行sudo make install安装版本时，默认配置为在内部安装该版本。原因是它隐式等效于运行：
./configure --prefix=/usr/local要在您的主目录中配置要安装的构建，请改用以下命令：
./configure --prefix="$HOME"实际上，在Ubuntu中，主目录路径不包含空格，其他空格或其他将由shell特殊对待的字符，例如*，因此，除非您对用户帐户进行了非常奇怪的设置，否则只需键入：
./configure --prefix=$HOME（不过，我不建议养成编写脚本的习惯。而且，在其他某些OS（例如macOS）上，用户主目录路径中包含空格的情况也很少见。）
或者，如果您愿意，可以键入完整的主目录路径：
./configure --prefix=/home/username（username当然，请用您的实际用户名替换。如果由于某种原因您的主目录不在其中，/home则必须进行相应的调整。）
运行之后make，您可能已经习惯了运行sudo make install，但是当您在自己的主目录中安装时，不需要以root用户身份运行它，因此可以-并且应该-省略sudo。赶紧跑：
make install同样，对于支持uninstall目标的软件：
make uninstall这正是您要的...，只是在您的主目录中/usr/local。
bin您的主目录的子目录可能是：
$PATH，或$PATH如果您只是注销并重新登录，它将在您的手中。原因是.profile您的主目录中的文件包含登录时运行的命令，默认情况下，该文件包含在大多数 Ubuntu 版本中创建的用户帐户（包括在安装OS时创建的初始管理员帐户）的文件：
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi该代码在您登录时运行（因为它在中.profile），并且仅在当时存在您的个人bin目录$PATH 时才将其放置在其中。这就是为什么您可能需要注销然后重新登录。
随之而来的是较旧的版本，如Ubuntu 14.04，以及较新的版本，如Ubuntu 17.10。但是，Ubuntu 16.04可能是本文撰写时最受欢迎的版本，它具有以下功能：
# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"只需将bin主目录的.local/bin子目录（以及子目录）添加到$PATH，而不检查这些目录是否确实存在。因此，如果您使用16.04，或者从创建用户帐户时从 16.04的系统升级，则bin主目录的子目录可能已经在您的中$PATH。
您的.profile文件从复制/etc/skel创建用户帐户时，目录。如果您的用户帐户是在较旧的Ubuntu版本上创建的，则该版本具有的版本.profile，并且对于您的用户帐户，它并没有通过升级到最新版本进行更改。
一旦bin您的主目录的子目录位于您的目录中$PATH，您就可以运行其可执行文件已安装在其中的程序，只需键入它们的名称即可，就像使用Ubuntu的软件包管理器安装的程序或安装在其中的程序一样/usr/local。
.local选项您可能已经注意到，.profile在某些Ubuntu版本（包括如上所述的16.04）中创建的用户帐户的默认文件不仅会添加$HOME/bin路径，还会添加$HOME/.local/bin。如果您.profile没有添加，但是想要添加，则只需对其进行编辑。
尽管通常用于存储设置和缓存的数据，但是您也可以.local在主目录的子目录中安装软件。你应该感到不羁这样做，因为从可用性和安全性的角度来看，--prefix="$HOME/.local"是类似--prefix="$HOME"。
请记住，.默认情况下，以图形开头的文件和目录在图形文件浏览器中（使用Ctrl+ H取消隐藏和重新隐藏）或通过ls命令（通过-A或-a标志显示）都不会显示。这可能不是您想要的，或者可能正是您想要的。这是个人喜好问题。
但是，我已经观察到某些在源代码的基础上自动构建和安装软件的基于源的自动化软件包管理器$HOME/.local。我实际上不知道这有多普遍-我希望进一步调查并更新此答案-但您可能更喜欢仅将其$HOME用于手动编译的东西。这样，就可以清楚地知道事情是从哪里来的。而且，如果发生冲突，该软件仍然可以共存。
您也可以故意在中安装某些软件，$HOME/.local并在中另外安装其他软件$HOME。由你决定。如果环境变量中第一个bin出现的目录$PATH是命令运行的目录，则两个目录中都存在相同名称的命令。
幸得赞纳和Videonauth对指出错误在以前的版本这个答案的，关于它的Ubuntu版本在其默认代码.profile，并帮助我纠正他们（见这里）。