主页 / unix / 问题 / 790400
Accepted
stickynotememo
Asked: 2025-01-31 18:49:56 +0800 CST

如果我是系统上唯一的用户，为什么 chmod 777 这么糟糕？

  • 772

我听说这chmod 777是个糟糕的主意。但是，没有人会使用我的系统（对于许多 *nix 系统来说，这是一种相当常见的情况）。为什么我不应该允许一切？

permissions

5 个回答

  1. Best Answer

    您可能是系统上唯一的人类用户。但如果您仔细查看，/etc/passwd就会发现还有很多其他用户：

    root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin
vnstat:x:101:102:vnstat:/var/lib/vnstat:/bin/false
redis:x:102:103:redis:/var/lib/redis:/bin/false

    这些是系统帐户，即在系统上运行不同服务和守护进程的帐户：Web 服务器、邮件服务（传入和传出）、ftp 服务器、cron 作业等。

    通常这些服务在自己的目录中运行，并像好孩子一样做它们的事情。但是，如果出现错误，或者更有可能的是，如果有人通过这些服务之一（例如 Web 服务器）入侵您的计算机，您不希望这些用户帐户对整个系统拥有不受限制的完全读写访问权限。

    简而言之，向这些用户提供超出其需要的访问权限，你不会得到任何好处，反而会失去很多。这称为最小特权原则。

    （注：密码文件取自这里。）

    • 42

  2. 你问，

    我听说 chmod 777 是个糟糕的想法。[…] 为什么我不应该允许一切？

    然后在评论中提到，

    我在让 Steam 下载另一个文件系统上的游戏时遇到了权限问题

    如果它是 Linux 原生文件系统，您可以将挂载点更改为您的所有者，或者您必须将其设置为所有用户均可写。由于最小特权原则，第二种选择并不理想：除非必要/适当，否则您不会授予访问权限。您无法预测会发生什么，因此您不会允许您不期望的事情。

    例子

    # Take ownership
sudo chown "$USER" /path/to/mountpoint

    如果你已经以 root 身份下载了项目，但实际上应该以自己的身份下载，请使用递归标志来获取文件系统挂载点下的所有内容的所有权

    sudo chown -R "$USER" /path/to/mountpoint

    请注意，如果您在/系统目录或任何系统目录上尝试这些命令，您将会破坏您的系统。

    • 13

  3. 一个重要的技术原因是，一些与安全相关的程序拒绝处理权限太过宽松的文件。例如，除非文件具有非常严格的权限，否则sshd不会使用它.ssh/authorized_keys。

    其次，您可能会因为意外删除或破坏文件或其他原因而导致系统无法启动/etc。强迫自己使用sudo或修改这些文件是避免自己犯错的一步。

    另一个更心理的原因：在 Unix*ish 系统上，处理权限是您将不断做的事情。如果您习惯于在任何地方应用 777，那么您将永远不会遇到与“真实”系统相关的小细节（即那些不仅由一个人使用、应用程序数量非常有限且没有安全相关数据的系统）。这意味着您正在剥夺自己习惯这一点并培养对这些事物如何运作的直觉的机会。

    毕竟，一旦你“熟悉”了权限系统，它就会变得非常非常简单。默认设置（即默认 umask 等）在现代系统中是“合理的”，因此在大多数情况下，你可以使用它；特别是当你独自一人使用系统时。

    如果您曾经在更敏感的系统上工作，特别是在商业环境中，您会很高兴权限是第二天性。

    • 2

  4. 对系统文件和目录应用 chmod 777 将会破坏你的系统

    这个问题让我非常感兴趣，所以我chmod -R 777 /*在我家的 rhel-9.4 系统上做了这件事。正如预期的那样，/run文件夹响应了只读文件系统，/proc文件夹没有被占用。这样做之后，我能够yum update成功重新启动并登录到 rhel-9.5。然而，详细启动确实显示安全审计服务和 ssh 服务失败，而 ssh 明确地将其关键文件权限识别得太开放，所以它无法启动。然后 Firefox 会打开，但尝试访问任何网站时都会显示“无法访问”，就像互联网不起作用一样。

    所以说破坏你的系统有点脱离上下文。我的意思是，如果根本没有互联网或网络访问，它就是完全独立和孤立的，然后是处理权限相关内容的东西/服务，但一般来说，如果你不需要它们，那么很难确定全局 chmod 777 的后果。你基本上是在说让一切运行，除了我提到的一些合理的例外，我认为事情会继续。

    现在，您没有明确说明在哪些文件夹上执行 achmod 777会发生什么。所以，假设在chmod 777 /steam只有一个文件夹的情况下执行某些操作，很抱歉让很多人失望，但在过去 20 年的工作中，我已经处理过这个问题，可以追溯到 SGI IRIX 时代，并且NO achmod 777从根本上来说并不是坏事。 这在很大程度上是一个上下文问题，如果有其他合乎逻辑的合理安全性，例如只有一个用户和物理位置是单用户自动登录设置的主要安全机制，则可以执行 777 并且不会引起问题。这就像说内部锁箱不好，而它已经在锁箱里面了。我确信您可以 chmod 777 很多系统文件并拥有一个正常运行的系统，但是只有懒惰的不太聪明的人会在整个系统范围内挥舞锤子来解决不是系统范围的问题。

    在您使用 steam 游戏的背景下，这意味着互联网，这意味着第三方软件、错误和安全，以及与其他用户对战，在 Linux 上对所有 steam 的东西进行统一的 chmod 777 是否可以，我不知道。我不会打赌 1 美元可以。

    • 1

  5. 我为什么不应该允许一切？

    因为即使您的一个假设是错误的，系统上基本的安全性也不会彻底失败。

    原因是它为您提供了更高的安全性，至少在某种程度上限制了权限处理，以便服务 XYZ 中的下一个错误不会将您自制的色情收藏和银行详细信息泄露给全世界。

    • -1

相关问题