从某种意义上说,这是一个与历史相关的问题,与 Linux 的用例紧密相关。如果它与主题无关,我愿意关闭它。
为什么sudo
在使用包管理器安装时总是使用默认值,即使没有技术上的必要性?
也就是说,我想vim
在多用户服务器上安装,而获得 sudo 访问权限是一种官僚主义的痛苦。在应用程序映像(或类似的)之前,唯一的选择是在主位置进行编译和安装。
造成这种情况有什么历史原因吗?或者我错过了幕后的一些技术原因?
答案1
我将在序言中指出,这个答案更具体地说明了为什么sudo
需要包管理。
需要系统级权限来完成系统级任务是有意义的。从历史上看,Linux 继承了类 Unix 的传统,在设计时就考虑到了多用户设置。为了防止用户互相干扰并更好地管理对系统的控制,系统管理员被授权能够控制和限制用户对根或系统级活动的访问。
这里简单介绍一下sudo
来自sudo 官方网站(强调我的):
须藤(“s替代品你塞尔做") 允许系统管理员授予某些用户(或用户组)运行某些(或全部)命令的能力根同时记录所有命令和参数。 Sudo 按命令运行,它不能替代 shell。其特点包括:
能够限制用户可以在每个主机上运行的命令。
Sudo 对每个命令进行大量记录,提供清晰的审计跟踪,了解谁做了什么。当与
syslogd
系统日志守护程序一起使用时,sudo
可以将所有命令记录到中央主机(以及本地主机)。在 CU,所有管理员都使用sudo
root shell 来利用此日志记录。Sudo 使用时间戳文件来实现“票务”系统。当用户调用
sudo
并输入密码时,他们将被授予 5 分钟的票证(此超时可在编译时配置)。每个后续sudo
命令都会将票证再更新 5 分钟。这避免了留下 root shell 让其他人可以物理访问您的键盘的问题。用户还有一种简单的方法可以删除其票证文件,这对于放入文件很有用.logout
。Sudo 的配置文件(sudoers 文件)的设置方式使得同一个 sudoers 文件可以在许多计算机上使用。这允许集中管理,同时保持在每个主机的基础上定义用户权限的灵活性。
现在来解决需要 sudo 的包管理问题。但情况并非总是如此。这是相关的 AskUbuntu 帖子涵盖这个主题。正如用户 Braiam 指出的,apt-get
需要 sudo,因为很多时候在安装软件包时,您需要系统级访问权限来安装和写入系统目录。
然而,正如他还指出的那样,人们可以使用它apt-get
来下载软件包并将其安装到非特权用户有权访问的位置。示例包括使用apt-get download
或 just plain oldwget
将软件包下载到当前目录,然后用于dpkg
安装该软件包。
问题在于,从管理角度来看,这是一个令人头痛的问题。用户将通过每个软件及其依赖项的副本使用不必要的磁盘空间,某些软件有时可能是恶意的或以引入漏洞或其他问题的方式运行,并且允许自由安装并不意味着允许人们快速审核和更新系统上的软件。包管理器允许集中控制以及审核和信任包来源的能力。
此外,正如用户 Ulrich Schwarz 指出的那样,主目录可能会挂载到带有以下标志含义的分区noexec
:
...即使您可以访问编译器,在共享系统上从主目录运行(可能耗费 CPU 的)二进制文件可能也很困难。
我也会链接到这个 U&L 堆栈交换帖子询问“为什么我几乎所有事情都必须使用 sudo?”。我相信这些答案足以支持我在这篇文章中的观点。您还可以了解更多关于sudo
on的历史维基百科。
结论
sudo
于 1980 年代初开发,允许用户以另一个用户(默认为超级用户 (root))的安全权限运行程序。它还为系统管理员创建审计跟踪和基于角色的访问控制系统。在类似 *nix 的系统上安装软件通常是通过包管理器完成的,但这并不总是必要的。包管理是一项系统级任务,管理员通常希望能够控制和审核,因此它通常受到限制以满足这些需求。