我想确保我的系统用户不能修改文件+ x，而且我不希望/ home /或/ var /中的任何内容成为可执行文件。
我不能把它们放在单独的分区上。
运行Ubuntu 9.04服务器。
我打算给chmod或者其他东西提供一个包装器，但是我越想到它，用户终究会find一个解决方法（从另一个盒子scp或者运行perl -s“chmod（'FILE'）; “等等…
所以，我认为FS方法是最好的。 既然你说你不能把它们移动到一个新的文件系统，那么使用–bind mount来“remount”/ home和/ var没有exec权限呢？
mount -o noexec --bind /var /var mount -o noexec --bind /home /home 我不确定这是否有效，但似乎很有希望…
编辑：
那么，我喜欢这个答案，我的漂亮，shiny的“好答案”徽章，但玩完后，我不认为它会奏效。 我原来的testing是在一个旧的（2.4.9）内核上，“挂载”function似乎工作。 我用一个更新的内核（2.6.18）再次尝试，它似乎不工作。 我开始研究周围的工作（比如将/ var和/ home重命名为其他东西，然后将它们重新安装回去，但是我并没有太多的了解，因为我发现这是在更新的包装盒的手册页上find的：
请注意，文件系统挂载选项将保持与原挂载点上的选项相同，并且不能通过将-o选项和–bind / -Rbind一起传递来进行更改。
呃…绑定仍然是一个有趣的select…
我可以想到这样做的两种方式，一种是肮脏的，另一种是好的。 我们先从肮脏的开始。
编写一个非常有规律运行的shell脚本，比如每5分钟或10分钟。 它会明确地从这两个目录中的所有文件中删除exec标志，即
chmod -R ugo-x /home /var
更好的方法是在文件系统级别执行。 创build新的分区来容纳var和home，无论如何，这被认为是最佳实践。 然后添加“noexec”选项进行安装。 这将防止在文件系统级执行存储在这些目录中的文件。
这是这样一个应该回答的问题的完美例子：
您似乎已经想出了解决复杂问题的解决scheme，现在正在询问有关如何实施此解决scheme的具体问题。 你能不能描述你正在试图解决的原始问题？
我的经验是，系统pipe理员知道何时以“什么？为什么？”来回应请求是非常重要的。 如何重要取决于用户描述他们原来的问题的倾向性，或试图提出自己的解决scheme，并要求协助实施它们。 在某些环境下，昂贵的灾难性的不好的解决scheme和廉价的好的解决scheme之间是不同的。
不要忘记确保/ tmp / var / tmp和其他用户可写的目录也挂载在带有noexec标志的分区上。
猜猜你也可以用-r，-m和-e attrib选项使用inotifywait来重置-x标志，如果它是由用户设置的
听起来像你有一个政策问题…
…大概这是由一个真正的问题，而你是偏执狂。
你不是在限制计算平台的有效性吗？
许多脚本可以通过直接调用解释器来运行：
sh ./mybashscript.sh
perl ./myperldaemon.pl
所以大概你试图阻止本机可执行文件运行？
最好通过政策和监督/审计来处理这个问题。
最好的情况是，你只会让那些经验较less的用户无论如何也不愿意。