shell脚本执行权限反转

shell脚本执行权限反转

假设某人在当前工作目录中有一个名为 Foo.sh 的 shell 脚本。它读起来像

#!/bin/bash
#some scripts below

为了通过输入“./Foo.sh”来运行脚本,他需要执行权限。相反,他可以选择通过简单地执行“bash Foo.sh”来执行脚本,并将脚本作为参数传递给程序 bash。在后一种情况下,他只需要读取权限。

这对我来说似乎是权限倒置,即用户可以执行他无权执行的可执行文件。

我的问题是:

  1. 这是一个有一定合理性的有意设计,还是一个遗留问题,仅出于兼容性原因而保留?

  2. 这是否有一些安全隐患?

答案1

这是一个方便的装置。 shebang 行将解释器硬编码到脚本中。除了方便之外,它还提供信息,就像文件扩展名一样。您仍然可以使用任何其他解释器运行它:

bash script.undefined

或者

sh script.undefined

或者可能

perl script.undefined

ETC。

从安全角度来看,这是一样的。无论哪种情况,都会使用活动用户的有效用户 ID 来读取和执行文件。粘性位对解释语言没有影响,但那是另一个故事了。 (事实上​​,这一点对于安全影响很重要。)

答案2

从技术上讲,它按照预期的方式工作。当你跑步时

./foo.sh

您正在运行 foo.sh 程序(在 shebang 的帮助下)

但当你跑步时

bash foo.sh

从技术上讲,您正在运行 bash 程序(/bin/bash 或 /usr/bin/bash)。

如果您担心安全问题。假设用户具有foo.shfoo.sh的读取访问权限,并且用户将其内容复制到bar.sh其中execute access。因此,在所有情况下,如果用户可以读取.sh文件,他/她就可以轻松执行它。

答案3

这只是“一个人的数据是另一个人的程序”这句老话的结果。计算机是基于冯·诺依曼架构构建的,这意味着文件中没有任何固有的内容表明“这是可执行文件,而另一个不是”。您编写的任何散文文本在由合适的解释器解释时都可以充当程序。

因此,如果文件包含需要隐藏的信息,则需要对其进行读保护。执行保护没有帮助。即使您有一个已编译的程序,您对其执行保护,但不对其进行读保护,我也可以轻松运行它。我只需要复制它,在副本上设置执行权限,就完成了。

因此,如果你想安全,你必须从文件和文件所在的目录中删除读取权限,而不是执行权限。

相关内容