我知道下面的脚本有一个严重的问题，NOEXEC 和 RESTRICT 不足以解决这个问题。
user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
但是，我对这两个选项仍然有些困惑。
限制
由于大量程序提供 shell 转义功能，将用户限制在不提供 shell 转义功能的程序集通常是行不通的。
为什么这是个问题？我不应该允许普通用户执行任意命令，因此将普通用户限制为不允许 shell 转义的程序似乎与 sudoedit 相同。这与 sudoedit 有什么不同？
诺执行
已知 noexec 功能可在 SunOS、Solaris、*BSD、Linux、IRIX、Tru64 UNIX、MacOS X、HP-UX 11.x 和 AIX 5.3 及更高版本上运行。
如果您不确定您的系统是否能够支持 noexec，您可以随时尝试并检查启用 noexec 时 shell 转义是否有效。
有没有好的方法来检查 NOEXEC 是否正常工作？尝试发出命令是最安全的吗？
答案1
限制
我解释“限制用户使用不允许 shell 转义的程序集通常是行不通的”，这意味着对于表面上似乎执行单一安全任务的程序来说，这是很常见的，但是实际上允许用户运行任何其他程序，在一般情况下，人们应该假设，授予用户对单个命令的访问权限实际上将允许他们运行他们想要的任何命令。
典型的例子可能是文本编辑器：除了允许用户从编辑器中打开任何文件（而不仅仅是命令行上给出的文件）之外，流行的编辑器还允许用户启动完整的 shell。
sudoedit 机制提供了一个只能编辑特定文件的编辑器（通过为用户提供要编辑的文件的副本，让他们自己编辑它，只有在更新特权文件之后）。如果要使用 RESTRICT 让用户在特定文件上运行（例如 emacs），那么该用户在以特权用户身份运行的 emacs 编辑器中实际上可以编辑该用户可访问的任何文件，并启动 shell作为该用户。
诺执行
当程序以这种方式启动时，其正常的动态库将被替换以禁止生成新的 shell。less如果这less是一个动态可执行文件，那么尝试从内部启动 shell 命令应该会失败。在想要允许编辑特定文件的情况下，用户使用 sudoedit 可能更安全、更好（因为这样他们就可以访问自己编辑器的自定义设置）。
至于检查 NOEXEC 是否可以在您的系统上运行，我假设它可以在文档中列出的任何操作系统上运行，前提是目标程序确实是动态链接的。但正如文档所建议的那样，最好手动检查。