☰

shell脚本执行权限反转

tag-icon • tag-icon bash shell-script 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

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

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

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

相关内容