Why does Bash's source not need the execution bit?

source or the equivalent but standard dot . do not execute the script, but read the commands from script file, then execute them, line by line, in current shell environment.

There's nothing against the use of execution bit, because the shell only need read permission to read the content of file.

The execution bit is only required when you run the script. Here the shell will fork() new process then using execve() function to create new process image from the script, which is required to be regular, executable file.

The execution bit (unlike the rest) on nonsetuid and nonsetguid files isn't much of a security mechanism. Anything you can read, you can run indirectly, and Linux will let you read anything you can run via /proc.

It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly (bash the_script; or cp /proc/$something/exe /tmp/mycopy && chmod +x mycopy).

You can set it for convenience if you intend to both in-source and execute your insourcable.

Another point of view:

Sourced script basically consists of shell builtins and program calls. Shell builtins (with source among them) are parts of the shell and the shell must be executable in the first place. Every program called (that being ELF, another script with shebang, whatever) has to have execution bit set, otherwise it will not run.

So it is not against the use of an execution bit, because nothing without execution bit will run. The validation doesn't occur for the sourced script as a whole; it is performed for every part separately, but it is.

The distinction is important because you may have a file of shell commands which is not useful as an executable, but only useful when sourced. For this file you can turn off the execute bit and then it will never be accessed unless explicitly in a source command. The reason for such a thing is to have side effects on the shell it is run from. For a specific example, I have a script called fix_path which looks at and modifies the path.

That's a good question! Unix uses the executable bit to distinguish between programs and data. The OS does not require the execution bit, since a sourced script is not passed to the OS for execution as a new process. But the shell treats a sourced script as a program, and will look in $PATH for the file you want to source. So, the shell itself could have required execute permission for sourced files; but it didn't.

The question must have come up long ago. The design of the Bourne shell was the result of "a long sequence of modification, dialog, discussion" among the denizens of Bell Labs, and many design decisions were discussed by S.R. Bourne and others over the years. Unfortunately, my quick look didn't find any discussion of the source feature (in my defense, it's hard to google for it). What I did find is that the "." command does not appear in this early introduction to the shell by Bourne himself, but it is present in the more mature Version 7 version.

Absent authority, here's my own interpretation:

1. The . command, aka source, is in effect textual inclusion (like #include in the C preprocessor) into the source code of the executing script or interactive session. As such, the included file is arguably not "executed".

2. The Unix philosophy has always been to give the programmers enough rope to hang themselves. Too much hand-holding and arbitrary restrictions just get in the way. (It is only rather recently that some distributions made rm -r / refuse to do what you ask. Do not try this as root!) So, perhaps Bourne at al. just decided that when you try to source a file, you are assumed to know what you are doing. That also avoids unnecessary work, and cycles mattered a lot back then.