在 macOS 的 zsh 终端中，我运行了以下命令：
cd /tmp
mkdir newdir
cd newdir
touch file1
./file1
最后一条命令返回
zsh: permission denied: ./file1
但运行
sh file1
文件时没有出现任何错误。
我已阅读有关如何运行sh filename使用 sh 解释器明确执行文件的信息。 sh 解释器具有允许其运行的附加权限file1。
但是，我还看到，在我的情况下，使用默认解释器./file1执行。所以我尝试运行file1zsh
zsh file1
但这也能无错误地执行文件。
问题：
为什么交互式 shell 没有权限运行该文件，但同时又有权限使用解释器执行sh, bash, zsh？
sh, bash, zsh此外，查看目录中的权限\bin表明该other组对其具有执行权限：
-rwxr-xr-x 1 root wheel 1.3M Sep 16 16:28 zsh
-r-xr-xr-x 1 root wheel 1.2M Sep 16 16:28 bash
-rwxr-xr-x 1 root wheel 131K Sep 16 16:28 sh
这是否意味着任何用户都可以使用拥有额外权限的解释器运行任何文件？
答案1
sh 解释器具有额外的权限，允许它运行 file1。
不，不是的。
那么为什么交互式shell没有权限运行该文件，但同时又有使用解释器sh，bash，zsh执行的权限呢？
就操作系统而言，解释器实际上根本不“运行”或“执行”脚本文件。它们只读它——然后它们根据文件中的内容执行操作。（因此得名“解释器”）。
因此，当您这样做时sh myfile，会发生什么情况？'sh' 读取一行，调用 chdir()；读取一行，产生/bin/mkdir；读取一行，再次调用 chdir()；读取一行，产生/bin/touch；... - 操作系统实际上并不知道或关心这些操作是代表脚本完成的。
（在 macOS 或 Windows 等系统上，解释器可能故意地通知操作系统它正在处理某个脚本（出于审计或安全策略目的，但它不必这样做。）
对于脚本来说，“执行”权限主要只是为了方便（和集成——与#!/bin/xxx标题一起允许脚本看起来和表现得像标准可执行文件），而不是作为任何类型的安全措施。
这是否意味着任何用户都可以使用拥有额外权限的解释器运行任何文件？
任何用户都可以使用任何解释器“运行”任何文件，只要解释器本身是可执行的。
也就是说，/bin/zsh 上的 '+x' 权限仅允许用户执行 /bin/zsh 本身 - 它不会授予 zsh 任何超出用户已有权限的特殊权限。
（有多种方式可以授予可执行文件一些特殊权限，例如“setuid”标志或 Linux“文件功能” - 使解释器“setuid”将授予解释中的任何脚本相同的权限 - 但通常不会这样做。）