How does bash make a file executable?

Question

I know that when I run the command

chmod +x filename

bash will make my file an executable. What exactly happens to the architecture of the file to change it to an executable? i.e. how does the kernel know that this file is executable?

Just trying to exercise my nerd muscles.

Answer 1

The "architecture" of the file doesn't change – it's up to you to make sure it has a correct format. That is, the file already needs to be a valid ELF binary, or a script with a valid #! header, or something else that your particular kernel recognizes (like a.out or MZ/PE).

What chmod does is just set a bit in the file's permissions telling the kernel that the user is allowed to execute this file. It can act as a small security barrier, as well as prevent certain kinds of accidents. (Note that +x here is shorthand for ugo+x; it's a permission bit just like read/write.)

If you set +x on a file that the kernel doesn't recognize, it'll just return an error code from the exec syscall. (Note that some shells have special handling for this – if the kernel reported "unrecognized format", the shell will try to interpret the file as a script internally, as that's how shellscripts worked before #! was invented.)

Answer 2

The file's contents don't change at all. Filesystems that are designed for typical Unix will support storing information about every file. This is often called the file's "meta data".

This is why you won't get similar results with some filesystems. Namely, FAT doesn't have built-in space designed for storing data related to Unix permissions, and Unix typically gets around that by using a special parameter when mounting such a filesystem volume. So, typically all files on a FAT drive have the same permissions, as specified by mounting. (I would expect similar behavior for other filesystems, like ISO9660, although that is probably usually unwritable.) On volumes mounted in this way, using chmod +x won't actually end up changing anything.

In short, the way the kernel knows this is by checking the filesystem driver. For typical filesystems designed for unix, that driver supports reading the locations where Unix-style permissions are stored.

chmod simply changes those spots on the drive.