在RHEL上挂载目录时,NOEXEC标志是什么意思?


11

我试图在安装时理解NOEXEC标志。

我在其他人的机器上的/ tmp目录中存在执行问题,我无法访问将/ tmp目录安装到与'/'不同的驱动器上并且存在NOEXEC的atm。我想尝试在计算机上重新创建此方案,但是没有第二个硬盘驱动器。我尝试执行以下命令:

mount --bind /test1 /test2

然后,我删除了该bind标志,并将其添加NOEXEC到/ etc / fstab中。然后,我在/ test2中创建了一个名为test.sh的文件,该文件仅呼应“ hello world”。我尝试运行它,并说“权限被拒绝”。然后chmod 777 test.sh,我运行并能够执行该文件。我以为NOEXEC标志不应该允许我执行任何操作?

mount --bind /test1 /test2不一样的,从一个完全不同的物理驱动器的安装?由于/ test1和/ test2在不同的驱动器上?


我怀疑您可能是绑定绑定某些特殊性的受害者。看到这个答案
卡米尔Maciorowski

Answers:


7

mount命令中的选项'NOEXEC'标志不允许在已安装的文件系统1中执行可执行二进制文件。但是,将脚本(以she-bang行开头的文本文件;即以开头的行#!)提供给某些shell(bash)时,它将运行该行上命名的可执行文件(例如/usr/bin/perl)并传递Shell脚本的路径作为第一个参数。实际的解释器可能不在该安装点上。
__________
1mount命令通常挂载文件系统。(可以说,环回或bind挂载可被视为这种一般性的例外。)在某些情况下(例如/tmp),此文件系统将仅包含一个目录。


因此,尽管sh文件位于/ test2中,但它正在/ bin / sh中而不是/ test2中执行?在另一台机器上,有一个Java进程正在将Shell脚本写入/ tmp目录,然后执行它们。我想我记得它创建的shell脚本#!/bin/sh位于顶部。除了通过Java和引用/ bin / sh之外,我不知道外壳脚本是如何执行的。如果它引用/ bin / sh并且bin目录具有执行特权,为什么shell脚本不会像我的测试中那样执行?
user972276 2014年

这完全取决于外壳程序/程序的调用,外壳程序脚本不是ELF的,无法直接执行,但是某些外壳程序将不允许运行已安装NOEXEC的FS上的脚本,它们只会死掉。在这种情况下,我不确定/ bin / sh的行为应该是什么。(特别是因为我不知道您使用的是哪种,所以有几种口味)。
KJ4IPS 2014年

想一想,当您使用外壳程序时,系统会注意到#!行,并调用适当的交易者(/ bin / bash /tmp/file.sh),但是如果java位仅在调用(/tmp/file.sh),则该行不通。
KJ4IPS 2014年

Java实例不在/ tmp目录中,需要使用解释器来执行shell脚本,对吗?除非Java具有内置功能,否则这意味着在/ tmp目录中仍然不会执行该操作。
user972276 2014年

在我看来,您的回答错误地声称,阅读shebang是壳的工作。看到这个答案
卡米尔Maciorowski
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.