TLDP 的高级 Bash 脚本指南指出不应将 shell 脚本用于“situations where security is important, where you need to guarantee the integrity of your system and protect against intrusion, cracking, and vandalism”。
是什么让 shell 脚本不适合这种用例？
【问题讨论】：
由于 shell 的延展性，很难验证 shell 脚本在面对敌对输入时是否执行其预期功能并且仅该功能。 shell 的行为方式取决于环境，以及它自己的众多配置变量的设置。每个命令行都受到多个级别的扩展、评估和插值。一些 shell 构造在子进程中运行，而构造包含的变量在父进程中展开。在设计可能受到攻击的系统时，所有这些都与 KISS 原则背道而驰。
【讨论】：
可能是因为它很容易搞砸。当PATH 设置不正确时，您的脚本将开始执行错误的命令。在字符串中的某处放置一个空格可能会导致它稍后变成两个字符串。这些可能导致可利用的安全漏洞。简而言之：shell 为您的脚本的行为方式提供了一些保证，但它们对于真正安全的编程来说太弱或太复杂了。
（对此我想补充一点，安全编程本身就是一门艺术，任何语言都可能搞砸。）
【讨论】：
我不同意这种说法，因为脚本本身并不安全。如果遵循一些简单的准则，Bash 脚本是绝对安全的：
将脚本与已编译程序分开的两点是源代码是可见的，以及解释器执行它。只要解释器没有受到损害（例如上面有一个 setuid 位），就可以了。
在编写脚本来执行系统任务时，拼写错误和错误以及编写时的一般人为错误在某种程度上代表潜在的安全故障，但编译程序也会出现这种情况（很多人倾向于忽略编译后的程序也可以反汇编）
值得注意的是，在大多数（如果不是全部）Linux 风格中，大多数（如果不是全部，事实上，想不出任何不是的）服务是通过 shellscript 启动的。
【讨论】：
【讨论】：