为什么/ usr / sbin中的可执行文件可以由root写入?


31

您能否解释一下为什么二进制编译文件(例如/usr/sbin)对root用户具有写权限?

对我来说,这是编译的。这意味着直接写入没有用,并且可能以某种方式使文件暴露于某些安全问题。

脚本(例如bash文件)可能是可写的,因为它基本上是文本文件,但是据我所知,为什么实际上不需要写入的编译文件也是如此?

预先感谢您的反馈。


6
只是为了澄清,您想知道为什么用户root对二进制文件具有写权限?如果没有其他帮助,则在升级该软件包时会有所帮助。
埃里克·雷诺夫

5
请注意,具有讽刺意味的是,二进制文件是我们通常直接在磁盘上直接写入/编辑的唯一文件。我们无法使用脚本之类的文本文件来执行此操作,因为文本修改不涉及写入文件,而是在文件中间添加额外的字节或在文件中间删除字节。使用fseek fwrite不可能做到这一点。因此,对于文本文件,我们通常读取到RAM,然后删除旧文件,然后将RAM的内容写入磁盘(即,我们将其覆盖)。另外,在安装,移动或替换可执行文件时,您正在写入磁盘,因此需要写入权限。
slebetman

1
@slebetman:您可以直接编辑文本文件。例如,打开文件,对其进行扩展,对其进行内存映射,使用memmove()将最后一部分移至末尾并打开一个孔,然后将新文本插入该孔。或者,您可以使用一系列pread()/ pwrite()来做同样的事情。
Zan Lynx

6
@EricRenouf其实,对二进制文件的写权限并不需要升级包含它的包。在软件包升级时,不会写入旧的二进制文件。实际上,如果二进制文件当前正在运行(搜索ETXTBSY),则这是不可能的。而是删除旧的二进制文件,并将新的二进制文件写入同名的新文件。删除文件不需要对其进行写许可,而只需要在包含目录(即/usr/sbin/)上具有写许可权。
marcelm

1
@marcelm:严格来说,您不仅在使用fseek并编写,还将其余部分缓冲到RAM中。您还可以将其余部分缓冲到另一个文件中。或者,您可以将新内容写入新文件。这些都不允许您在没有某种大缓冲区的情况下扩展文本文件。
slebetman

Answers:


50

/bin根目录下的文件(或保留可执行文件的任何其他标准目录)中的文件是否可以由root写入并不重要。在我正在使用的Linux服务器上,它们可以由root写入,而在我的OpenBSD机器上则不能。

只要它们不能由组或“其他”写!

没有安全问题,例如

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

如果有人想覆盖它,他们必须是根,如果他们是root和覆盖它,那么他们要么

  1. 安装新版本,或
  2. 笨拙的,或
  3. 具有root权限的攻击者。

要考虑的另一件事是,无论根是否受到写保护,root都可以将其写入文件,因为... root。

还要注意,“脚本”与二进制文件一样,都是可执行文件。脚本不需要是可写的,因为它是文本文件。如果有的话,它可能应该与同一目录中的其他可执行文件具有相同的权限。

现在不要去更改所有内容的权限!这可能造成各种破坏,并可能使可能会验证权限设置正确的程序包管理器感到困惑。如果您不小心更改了安全性至关重要的应用程序上的权限,也可能使系统容易受到攻击。

只要假设可执行文件的权限设置正确即可,除非您发现看起来确实很奇怪的东西,在这种情况下,您应该联系相关的软件包维护者进行验证,而不是开始进行更改。


从评论和聊天中,有一段历史的呼唤。

对Linux上的二进制文件的权限的历史一无所知。可以推测,他们只是从目录或仅从umaskLinux 的默认继承了权限,但我真的不知道。

我所知道的是,OpenBSD 默认在许可模式555下将二进制文件安装在基本系统1中-r-xr-xr-x)。这是在Makefile片段中指定的,该片段/usr/share/mk/bsd.own.mk设置BINMODE为555(除非已设置)。稍后在make buildin中安装可执行文件时使用/usr/src

我查看了该文件的带注释的CVS日志,发现该文件中的这一行自1995年从NetBSD导入以来未更改。

在NetBSD上,该文件于1993年首次放入CVSBINMODE设置为555。

FreeBSD项目似乎至少从1994年开始就使用了与NetBSD完全相同的文件,并且在以后的提交中,在提交消息中添加了一个提示,即旧文件来自Berkeley Software Distribution的4.4BSD版本。

除此之外,伯克利的CSRG将源代码保存在SCCS中,但是它们的存储库在GitHub 2 上以Git形式提供。我们要在这里给forencic treatement文件似乎一直致力于通过基思·博斯蒂克(或有人接近他)于1990年。

那就是那个故事。如果您想要为什么,那么我想我们不得不问基思。我有点希望看到一条提交更改的提交消息,说“ 这必须是555,因为... ”,但是没有。

1 BSD系统比Linux更严格地划分为“基本系统”和“第三方软件包”(端口/软件包)。基本系统是一个连贯的单元,为运行操作系统提供了一套完整的功能,而端口或程序包则被视为“本地软件”,并安装在下/usr/local

2 从70年代开始,也可以获得更全面的Unix版本的GitHub存储库。


1
谢谢您的回答。写权限是正常的,因为作为root用户(他可以执行任何操作)并不重要。但是,由于这并不重要,如果一开始就相同,为什么不设置不写权限呢?这是武断的决定吗?
t1m0th33

1
@ t1m0th33我相信这可能是某人做出的任意决定,是的。就像我说的那样,在OpenBSD系统上,这些位置的文件不可被写入root
库沙兰丹

1
我认为这不是任何人的有意识决定。程序包管理器默认使用在构建过程中最终获得的许可权位来安装文件;在构建链接器时,使用755权限创建了文件,因为这是从777减去umask时得到的,并且(在OS供应商的构建机器上)umask根在构建时的值为022,因为022是每个人和root为222将是毫无意义的额外工作。
Henning Makholm '17

8
为“不要立即更改所有内容的权限!” + 1 我在Ask Ubuntu上看到了很多类似的问题,用户chmod -R/usr或上做了什么/var,并且感到惊讶-它们sudo不起作用或其他功能不起作用。
Sergiy Kolodyazhnyy

4
从历史上看,缺少对root的写许可不会有任何效果(root可以chmod任何东西,甚至不需要,因为root永远不会在打开或写入时获得EPERM)。我想知道这555项内容是否开始,是因为实际上实际上已经可以限制root了(何时首次显示安全
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.