Yes, I know
About the Execute Bit

To start, let’s go back to the very basics. It is the role of the filesystem to organize things on a disk so you can store and retrieve your files. There are numerous different filesystems supported on a typical Linux system: Ext3/4, XFS, ZFS, BTRFS just to name a few. A filesystem has the exclusive use of a given storage area. However, if you have multiple disks or multiple partitions on the same disks, you may very well have different kinds of filesystems in use simultaneously on your system.

For example here are the filesystems currently in use on my laptop while I type this text:

The job of the file system is to store and retrieve your files. In addition to the file content, they also manage a set of metadata associated with that content. It could be, for example, the file name, the file owner, the latest modification date, or, for what interest us today, the file’s permissions.

For things to be a little bit less abstract, let’s consider that sample file:

You can see many metadata are associated with the file. You may eventually be more familiar with the output of the ls -l command that displays the most useful subset of that information:

The traditional file permissions (as opposed to Unix ACLs) are stored using at least 9 bits. A bit is just a fancy name for a flag that can be either true ("set") or false ("clear"):

For my sample file, you can see:

Instead of the symbolic rwx flags, you will sometimes encounter their numeric octal counterpart. In that format, the x flag has the value 1, the w flag has the value 2, and the r flag has the value 4. So, rwx can be written numerically as 7 (that is: 4+2+1). I let you make the necessary calculations to check that, as indicated by the stat command, the rwxr-xr-- permission is equivalent to the octal number 754:

When talking about standard Unix permissions, we cannot avoid mentioning the chmod(1) command. It is the canonical tool to change file permissions. Here also the permission can be specified either as numerical values or as symbolic values. In that latter case, the syntax is somewhat different from the output of the ls and stat commands. Here are a couple of examples:

As an exercise to check your comprehension, I let you now complete the following table:

Unix-like systems do not have the notion of "executing" a directory. So the x bits, when applied to directories, has a different meaning. It is used to grant the right to traverse that directory.

The difference between the x and r bits for directories are easier to grasp on an example. So, let’s create first a directory containing a couple of dummy file:

Let’s remove now the x permission on the directory:

Now let’s see what the unprivileged user with id 1000 can do with that directory:

As you can see, despite the r permission, the ls command is not allowed to access the files stored in the directory. For things to be clear, you have to understand with those permissions, the user with id 1000 can read the list of files contained in the directory. However, (s)he cannot access anything through that directory (including the file’s metadata):

Let’s permute now the r and x flags so that users may have the traversal right, but no longer the read permission on the directory:

And do out little experiment again:

Interesting. Despite the missing r permission on the directory, the user was able to access the files stored in there. But only because I explicitly gave the path to those files on the command line. This implies I knew these file name in advance. However, with that setup, the user is no longer able to access the directory content—​so (s)he cannot obtain the list of files contained in the directory:

This feature that can be used to implement a basic kind of access control: by using a traversable but unreadable directory, you can grant people the right to read the content of files they know to be in that directory. However since the same people cannot see the list of files contained there—​they cannot know if there are other files in that directory, and without their name, they cannot read them.

I have said it earlier, modern operating systems support many different kinds of filesystems, including filesystems unable to store the Unix permission bits.

Let’s create a 512MiB VFAT disk image for the purpose of testing:

And let’s now populate our newly created file system with the same files as above:

You may have notice the FAT 32 filesystem add the implicit x permission on every created file or directory. And you can’t change it using chmod because that filesystem does not handle the standard Unix permissions at all:

Since that particular filesystem does not handle Unix permissions, some default value is provided by the operating system to userspace applications. Those default values are controlled filesystem-wise by specifying the fmask option at mount time. The fmask option is a mask, that is the list of permission that should be removed. For example, to remove the x flag to all files of my VFAT filesystem, I can mount it like that:

In addition to the fmask option, the mount command when applied to VFAT filesystems accepts the dmask option whose purpose is similar, but to apply a permission mask to directories rather than files. I let you experiment with the dmask option as an exercise.

Finally, if you want to prevent execution from a given filesystem you can also use the noexec mount option:

As you can see despite the x bit, we do not have the permission to run any executable file from that mount point. The noexec option is particularly useful if you want to prevent execution from a filesystem that otherwise supports standard Unix permissions. That way, you can still manipulate the permissions as usual, but no binary executable can be run. Particularly useful for removable media or kiosk systems.

To see the noexec flag in action, let’s create and mount an ext3 filesystem this time. This is a Linux filesystem that has full support for the standard Unix permissions. In that initial step, we will mount it without any specific option to observe its default behavior:

As you can see, the x flag is user-settable, and, as expected, when present for a file it will grant the execution right on that file. And now, let’s remount the same filesystem, but this time with the noexec options:

Permissions on the filesystem haven’t changed. Nevertheless, the kernel prevents the execution of any file from that filesystem now, regardless the presence or absence of the x flag on that file.

To conclude that article with a little bit of magic, using a combination of bind mount and remount on a Linux system, you can mount the same filesystem on two different mount points, one with exec permissions, the other one without it:

Since the options are enforced when the filesystem-level is mounted, the "trick" here is to use two real mounts (the initial one, and the remount one) with two different sets of options. Because of the "remount" option, this is actually different from mounting twice the same filesystem--something that isn’t supported by most of them (with the notable exception of shared disk filesystems like OCFS2). But we are entering now the realm of very specialized tasks. If I follow that path, I risk being more confusing than helpful, especially if you are new Unix-like systems. So, instead, take your time now to examine and experiment with the different example shown in that article to try figuring how they work. It is definitely the best way to understand your system!