假设某人在当前工作目录中有一个名为 Foo.sh 的 shell 脚本。它读起来像
#!/bin/bash
#some scripts below
为了通过输入“./Foo.sh”来运行脚本,他需要执行权限。相反,他可以选择通过简单地执行“bash Foo.sh”来执行脚本,并将脚本作为参数传递给程序 bash。在后一种情况下,他只需要读取权限。
这对我来说似乎是权限倒置,即用户可以执行他无权执行的可执行文件。
我的问题是:
这是一个有一定合理性的有意设计,还是一个遗留问题,仅出于兼容性原因而保留?
这是否有一些安全隐患?
答案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.sh
foo.sh的读取访问权限,并且用户将其内容复制到bar.sh
其中execute access
。因此,在所有情况下,如果用户可以读取.sh
文件,他/她就可以轻松执行它。
答案3
这只是“一个人的数据是另一个人的程序”这句老话的结果。计算机是基于冯·诺依曼架构构建的,这意味着文件中没有任何固有的内容表明“这是可执行文件,而另一个不是”。您编写的任何散文文本在由合适的解释器解释时都可以充当程序。
因此,如果文件包含需要隐藏的信息,则需要对其进行读保护。执行保护没有帮助。即使您有一个已编译的程序,您对其执行保护,但不对其进行读保护,我也可以轻松运行它。我只需要复制它,在副本上设置执行权限,就完成了。
因此,如果你想安全,你必须从文件和文件所在的目录中删除读取权限,而不是执行权限。