当给定一个带有无法识别的可执行幻数的文件时， posix_spawn() 应该如何表现？
glibc 实现 会尝试将文件发送到 /bin/sh：
__execve (file, argv, envp);
if (errno == ENOEXEC)
script_execute (file, argv, envp)
POSIX 示例实现 如果 execve() 以任何方式失败，就会失败：
execve(path, argv, envp);
exit(127); /* exec failed */
posix_spawn() 的 POSIX 规范 没有指定任何有关如何处理以下文件的信息：如果发送到 execve()，则结果为 ENOEXEC。作为可能的对比，exec* 系列函数的 POSIX 规范特别指出 execlp() 和 execvp() 在无法识别的可执行类型的情况下应调用 sh：
有两种不同的方式来显示过程映像的内容 文件可能会导致执行失败，通过设置来区分 errno 为 [ENOEXEC] 或 [EINVAL]（请参阅“错误”部分）。在 exec 函数族的其他成员将的情况 失败并将 errno 设置为 [ENOEXEC]、execlp() 和 execvp() 函数 应执行命令解释器和环境 执行的命令应类似于进程调用 sh 实用程序 使用 execl() 如下：
execl([shell 路径], arg0, 文件, arg1, ..., (char *)0);
其中 [shell 路径] 是 sh 实用程序、文件的未指定路径名 是进程映像文件，对于 execvp()，其中 arg0、arg1 等 on 对应于传递给 argv[0]、argv[1] 中的 execvp() 的值， 等等。
那么，glibc的实现是不是不符合规范呢？或者 POSIX 规范在这里有点模糊？ glibc的实现不存在安全风险吗？
The glibc implementation of posix_spawn tries sending the file to /bin/sh if execve() fails with ENOEXEC:
__execve (file, argv, envp);
if (errno == ENOEXEC)
script_execute (file, argv, envp)
The POSIX sample implementation simply fails if execve() fails in any way:
execve(path, argv, envp);
exit(127); /* exec failed */
The POSIX specification for posix_spawn() does not specify anything about how to handle files that would result in ENOEXEC if sent to execve(). As a possible contrast, the POSIX specification for the exec* family of functions specifically states that execlp() and execvp() should invoke sh in the case of an unrecognized executable type:
There are two distinct ways in which the contents of the process image
file may cause the execution to fail, distinguished by the setting of
errno to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the
cases where the other members of the exec family of functions would
fail and set errno to [ENOEXEC], the execlp() and execvp() functions
shall execute a command interpreter and the environment of the
executed command shall be as if the process invoked the sh utility
using execl() as follows:execl([shell path], arg0, file, arg1, ..., (char *)0);
where [shell path] is an unspecified pathname for the sh utility, file
is the process image file, and for execvp(), where arg0, arg1, and so
on correspond to the values passed to execvp() in argv[0], argv[1],
and so on.
So, is the glibc implementation non-conforming? Or is the POSIX specification just a bit vague here? Isn't there a security risk in the glibc implementation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
即使没有正式批准，这种行为对于 posix_spawnp 来说可能是可以接受的（通过类比），但我认为你是对的，它不符合规范，而且对于普通的
来说这是危险的不符合规范>posix_spawn。 shell 调用代码应该被简单地删除。This behavior might be acceptable (by analogy) for
posix_spawnp, even if not officially sanctioned, but I think you're right that it's non-conformant, and moreover that it's dangerously non-conformant for plainposix_spawn. The shell invocation code should simply be removed.