What does NOEXEC flag mean when mounting directories on RHEL?

11

2

I am trying to understand the NOEXEC flag when mounting.

I am having an execution issue within the /tmp directory on someone elses machine that I cannot access atm where the /tmp directory is mounted onto a different drive than '/' and NOEXEC is present. I wanted to try and recreate this scenario on my machine, but I do not have a second hard drive. I tried doing the following command:

mount --bind /test1 /test2

I then removed the bind flag and added NOEXEC in /etc/fstab. Then, I created a file in /test2 called test.sh where it just echos 'hello world'. I try and run it and it said 'permission denied'. I then ran chmod 777 test.sh and was able to execute the file just fine. I thought that the NOEXEC flag should not allow me to execute anything?

Is mount --bind /test1 /test2 not the same as mounting from a completely different physical drive? As in /test1 and /test2 are on different drives?

user972276

Posted 2014-03-12T17:08:20.337

Reputation: 637

I suspect you may be a victim of some peculiarity of bind mount. See this answer.

– Kamil Maciorowski – 2017-12-13T22:13:43.460

Answers

6

Option 'NOEXEC' flag in the mount command does not allow the execution of executable binaries in the mounted file system1. However, when a script (a text file that begins with she-bang line; i.e., a line that begins with #!) is given to some shells (bash), it will run the executable named on that line (e.g., /usr/bin/perl) and pass the path of the shell script as the first argument. The actual interpreter might not be on that mountpoint.
__________
1 The mount command typically mounts a file system.  (Arguably, loop-back or bind mounts may be considered an exception to this generality.)  In some cases (e.g., /tmp), this file system will contain only one directory.

KJ4IPS

Posted 2014-03-12T17:08:20.337

Reputation: 801

In my opinion your answer wrongly claims it's the shell's job to read a shebang. See this answer.

– Kamil Maciorowski – 2017-12-13T22:11:45.287

@Kamil While that is normally true, some shells check for shebangs separately. I'm looking at you pfksh... – KJ4IPS – 2017-12-14T23:06:47.713

Edited to cover the primary case, where the shell handles the shebang, and doesn't do anything strange to it. I was also less well-informed when I wrote this. – KJ4IPS – 2019-07-23T15:16:51.283

So, although the sh file resides in /test2, it is getting executed in /bin/sh, not /test2? On the other machine, there is a java process that is writing shell scripts to the /tmp directory and then executing them. I think I remember the shell scripts it is creating has #!/bin/sh at the top. I do not know how the shell script is getting executed other than its going through java and references /bin/sh. If it is referencing /bin/sh and the bin directory has execute privileges, why wouldnt the shell scripts execute like they did in my test? – user972276 – 2014-03-12T19:00:38.553

That's all up to the shell/program calling, shell scripts are not ELF's and cannot be directly executed, however some shells, will not allow a script on a FS that is mounted NOEXEC to run, they will just die. I'm not sure what /bin/sh's behavior is supposed to be in this case. (Especially since I dont know which one you are using, there are a few flavors). – KJ4IPS – 2014-03-12T20:27:35.887

Come to think of it, when you use the shell, the system notices the #! line, and calls the appropriated interpereter (/bin/bash /tmp/file.sh), but if the java bit is just calling (/tmp/file.sh), that is not going to work. – KJ4IPS – 2014-03-12T20:31:42.647

the java instance is not in the /tmp directory and would need to use an interpreter to execute shell scripts right? Unless java has that built in functionality, which means the execution still would not happen in the /tmp directory. – user972276 – 2014-03-13T18:29:20.990

Asked: 2014-03-12T17:08:20.337

Viewed: 33 720 times

Active: 2019-07-23T15:15:42.350