为什么对shell脚本禁用SUID，而不对二进制文件禁用SUID？

Question

虽然我理解SUID的思想是让非特权用户以特权用户的身份运行程序，但我发现，如果没有一些解决办法，SUID通常不会在shell脚本上工作。我的问题是，我并不真正理解shell脚本和二进制程序之间的二分法。看起来，无论用shell脚本可以做什么，也可以用C完成，并将其编译成二进制文件。如果SUID对shell脚本不安全，那么它对二进制文件也不安全。那么，为什么会禁止shell脚本而不是二进制文件使用SUID呢？

Answer 1

主要是因为

许多内核都处于争用状态，允许您将newly脚本交换为您选择的另一个可执行文件，即新的exec()ed进程进入setuid的时间，以及命令解释器启动的时间。如果您足够持久，理论上您可以让内核运行任何您想要的程序。

以及在该链接中发现的其他原因(但内核竞争条件是最有害的)。当然，脚本加载的方式与二进制程序不同，二进制程序就是其中的错误所在。

您可能会很高兴地阅读这个2001年年Dobb博士的文章 --它经历了6个步骤来编写更安全的shell脚本，但最终达到了步骤7：

第七课--不要使用shell脚本。即使我们做了这么多工作，也几乎不可能创建安全的shell脚本。(在大多数系统中，这是不可能的。)由于这些问题，一些系统(例如Linux)不会在shell脚本上使用SUID。

这段历史讨论了哪些变体对种族条件进行了修正；列表比您想象的要大。但是setuid脚本在很大程度上仍然因为其他问题而被劝阻，或者因为它更容易阻止它们，而不是记住您是在安全还是不安全的变体上运行。

这是一个足够大的问题，在过去，它是有教育意义的阅读如何积极的Perl来补偿它。