为什么nc的BSD版本1.10禁用在其他所谓的不安全分布中find的-e选项，即使使用“安全”版本的nc ，同样的危险特性也可以如下简单实现：
$ # Machine A $ mkfifo pipe $ nc -l 4000 <pipe | bash >pipe $ # Machine B $ nc MachineA 4000
现在，如果我要把A机上的咒语包含在一个脚本中（如果通过`-e“参数有效地实现了上述function），我基本上已经介绍了”大胆的安全漏洞“，而不必下台到Makefile和构build级别。
那么，为什么要在netcat.c中使用#define -ing netcat.c呢？
虽然我没有明确的答案，但我相信只有当你的nc启用了-e 并且是setuid root的时候才会出现大的安全漏洞。 （由于nc通常用于绑定到端口，因此可能会打包setuid root以使所有用户都能够绑定在1024以下的特权端口上。）
在这种情况下， nc -e会以root身份exec给定的进程 – 这意味着它将允许任何用户以root身份运行任何进程 。 我相信你会认识到这是一个巨大的安全漏洞。 相比之下，如果你运行自己的进程并使用pipe道将其连接到nc ，那么这个进程不会以root身份运行，除非你有其他的方法来提升它（比如sudo访问）。
正如grawity指出的那样，netcat的原始发布声明抱怨说
商业供应商可能打包了[netcat] setuid root并且打开了
-DGAPING_SECURITY_HOLE，但没有logging。
我认为，这给我的理论带来了压力。 🙂
我可以使用“netcat -e”运行其他应用程序，例如imap或pop3。 部分“#ifdef GAPING_SECURITY_HOLE”可能包含一个bug，允许你运行一个shell，这就是为什么它默认情况下被拒绝。 ifdef包装安全关键部分。
从原始发布公告 ：
强制供应商bash：如果“nc”几年前已经成为标准公用程序，那么商业供应商可能打包了setuid root并且打开了
-DGAPING_SECURITY_HOLE，但没有logging。 希望netcat能够帮助人们find并修复这种不断出现的这种不用脑子的漏洞，这样可以更容易地实验networking层的“裸机”。
并不是说它使得更清晰