☰

历史和解释

tag-icon • tag-icon linux unix authentication users
历史和解释

历史和解释

在 Unix 的早期，

... 因为 Unix 是作为网络和多用户操作系统发明的；您可以在 Unix 上部署 Web 服务器程序，其中程序中的在线用户与 Unix 机器上的实际用户（在 /etc/passwd 中注册，编号大于 1000）相同（相等）（如果我错了，请纠正我）。

如今，

...现在这种情况已不复存在。如今，每个希望为多个在线用户服务的 Web 服务器程序都包含在同一程序中编写的多用户支持。Web 服务器程序仅在以下情况下运行：一用户，通常这个用户的名字与程序的名字相同（例如 Apache 可能部署在用户 apache 或 www-data 下）。

比较

当今常规设置的缺点

  • 管理大多只能通过 Web 服务器程序（CLI、GUI 或 conf 文件）进行。
  • 我想说，管理会变得有点复杂和不透明。因为通过将其限制为仅一个用户；但随后创建多个用户里面应用程序/应用程序主目录；在我看来，整个多用户操作系统的概念都被滥用了。使用 SELinux 之类的东西或通过将这些人放入系统组中来限制访问权限不是更好吗：例如，您可以将所有在线用户放入名为 online-users 的系统组中。然后，您可以拒绝该组的所有成员在您的服务器上执行任何程序，除了您之前配置的 Web 服务器程序。这还会使同一服务器上的多个 Web 服务器应用程序之间的数据共享变得更加容易。
  • 每一个想要制作在线网络服务器程序的程序员，还必须编写多用户支持程序，并使每个用户彼此隔离，以便任何用户都无法访问其他用户的数据或密码 => 双重工作！
  • 这样，在线用户（Web 服务器应用程序内部）与服务器上的系统用户就得到了很好的保护；但是同一台服务器上的在线用户与在线用户的保护级别取决于 Web 程序程序员的编程技能。

当今正常设置的优势：

  • 更安全：通过限制全部在线操作和数据仅提供给一个用户（可以这么说：沙盒）不root/sudo 权限并且只有一个程序（当然没有 SUID 位）。
  • 可移植性：Web 服务器程序也可以在非 Unix 系统上使用。但是，Windows 或 Mac OS X Servers 很少用作 Web 服务器操作系统；这并不是一个很大的优势。


还有其他优点吗？如果这是唯一的优点（我不认为第二个优点相关...），我会将整个事情视为一个很好的例子，其中安全性比可用性/可理解性/透明度更重要。

除此之外，我认为还有更多我没有提到的优势。

我想你明白我的意思；我不必举例子。如果你不明白我的意思，我可以举一些例子。



总结：

为什么现在不再存在（基于 POSIX 的操作系统的） Web 程序；其中：
在线用户, 使用网络程序注册 ==系统用户，在 /etc/passwd 中注册，编号 > 1000。
每种设置的优点和缺点是什么（今天的设置：=/=，可能的设置：==）？

我找不到任何网站或其他 serverfault 问题，只是在从属条款中偶然处理这个问题，如果您知道一个网站或问题；请告诉我。

答案1

时代变了。曾经有一段时间，可以通过该服务器的主机管理员地址联系到每个系统的管理员。连接曾经取决于知道哪个管理员允许您访问，并且系统之间的路由图会定期发布。那些日子早已一去不复返，安全威胁无处不在。

userid > 1000 问题只是个幌子。通常的做法是为系统服务帐户保留 UID < 1000。其中一个是www-dataApache Web 服务器经常使用的帐户。这些 UID 上的服务可能由服务器管理员控制。这意味着如果我能联系到管理员，他们很可能会知道该应用程序并能够采取一些措施。

据我所知，所有服务器都不太关心用户的 UID 是什么。如果开发人员想要运行 Web 服务器、tomcat 等，他们可以自由地在非特权端口上执行此操作（见下文）。

特权端口（1 至 1024）通常需要 root 访问权限才能打开。这可确保其他管理员知道该端口上的服务已获得该服务器管理员的许可。非特权端口（1025 及以上）可由任何用户使用（如果尚未使用）。

在多用户系统中，您不能让一群用户都尝试在知名端口（例如端口 80）上运行服务。一次只能有一个用户可以绑定该端口。Apache 等程序允许这样做，并且每个用户都可以拥有自己的public_html目录，他们可以在其中发布 Web 内容，包括从该目录运行脚本的能力。此功能的可用性由管理员配置。

虽然出于测试目的，几乎任何人都可以为知名服务启动服务器。但是，其中许多都存在普通用户/开发人员不会意识到的问题。许多网站和营销服务器的配置方式使得很难判断服务器是否合法。如果您没有正确配置 rDNS、SPF、DKIM 和 DMARC，Google、Microsoft 和 Yahoo 等主要提供商会越来越难以向他们发送邮件。

相关内容