Sstrhsrtj

Can anyone explain in details what is going on with the following. Let's imagine I am mounting a directory with noexec option as follows:

mount -o noexec /dev/mapper/fedora-data /data

So to verify this I ran mount | grep data:

/dev/mapper/fedora-data on /data type ext4 (rw,noexec,relatime,seclabel,data=ordered)

Now within /data I'm creating a simple script called hello_world as follows:

#!/bin/bash



echo "Hello World"

whoami

So I made the script executable by chmod o+x hello_world (this will however have no effect on a file system with noexec options) and I tried running it:

# ./hello_world

-bash: ./hello_world: Permission denied

However, prepanding bash to the file yields to:

# bash hello_world

Hello World

root

So then I created a simple hello_world.c with the following contents:

#include <stdio.h>



int main()

{

    printf("Hello Worldn");

    return 0;

}

Compiled it using cc -o hello_world.c hello_world

Now running:

# ./hello_world

-bash: ./hello_world: Permission denied

So I tried to run it using

/lib64/ld-linux-x86-64.so.2 hello_world

The error:

./hello_world: error while loading shared libraries: ./hello_world: failed to map segment from shared object: Operation not permitted

So this is of course true since ldd returns the following:

ldd hello_world

ldd: warning: you do not have execution permission for `./hello_world'

    not a dynamic executable

On another system where noexec mount option doesn't apply I see:

ldd hellow_world

    linux-vdso.so.1 (0x00007ffc1c127000)

    libc.so.6 => /lib64/libc.so.6 (0x00007facd9d5a000)

    /lib64/ld-linux-x86-64.so.2 (0x00007facd9f3e000)

Now my question is this: Why does running a bash script on a file system with noexec option work but not a c code? What is happening under the hood?

Executing command on this way:

bash hello_world

you make bash read from file hello_world (which is not forbidden).

In other cases OS try to run this file hello_world and fail because of noexec flag

What's happening in both cases is the same: to execute a file directly, the execute bit needs to be set, and the filesystem can't be mounted noexec. But these things don't stop reading those files.

The noexec filesystem option just plain isn't as smart as you'd like it to be. In the case of the bash script run as ./hello_world, the #! line isn't even checked, because the system sees that it should ignore the executable bit before even trying to run the file.

In the case of bash ./hello_world, the script is never "executed" in the relevant sense. Instead, /bin/bash is, and that then loads the file and does stuff. In the case of bash or another shell, the "stuff" is "execute a bunch of commands", but _now we're "past" anything that's going to check file execute bits. That check isn't responsible for what happens later.

Consider this case:

$ cat hello_world | /bin/bash

… or for those who do not like Pointless Use of Cat:

$ /bin/bash < hello_world

The "shbang" #! sequence at the beginning of a file is just some nice magic for doing exactly the same thing — when you try to execute the file as a command. You might find this LWN.net article helpful: How programs get run.

Because the bash executable doesn't reside on said filesystem.