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 executable 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 indirectly read anything you can run but not directly read (that should be enough to punch a hole in the concept of non-set(g)uid x-bit being a security measure).

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 some hacking to get the memory image of a no-read-permission executable).

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

Apparently, however, many shared library implementers share your thinking and consequently, many systems do require that shared libraries, which are essentially the native equivalent of shell insourcables, be marked executable in order to be usable. See Why are shared libraries executable?.

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. (This command tells rm to delete everything on your computer. Do not try it as root! Or better yet, not at all.) 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.

As far as the OS is concerned, a file containing shell script is just data. If you pass the name of such a data file to the source command or pass it on the command line to an invocation of the bash shell, all the OS sees is a string that happens to coincide with the name of a file containing data.

How would the execute bit be at all relevant in that case?

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.

Just in case anyone is interested in further studies and/or clarification: In a nearly POSIX compliant shell implemented a while ago the internal workings of the 'exec_program()' and the 'builtin_source()' functions are very exemplary. In those functions you see exactly what is the difference between them:

https://github.com/rsenn/shish/blob/master/src/builtin/builtin_source.c

https://github.com/rsenn/shish/blob/master/src/exec/exec_program.c

basically sourcing can be seen as the shell temporarily redirecting its internal file descriptor where it parses shell script from (the terminal in interactive mode). so it is very similar to other redirections like <input_file.txt and >>append_to_something.list and these just need to open and close files.

so executing is handled by the execve() system call for which the execution bit is mandatory.

I recall seeing some systems which allow execution of ELF/a.out binaries, but via executing the "/lib/ld-dynamic-linker.so" and with the binary program (without exec bit) as first argument. I believe that was on some DEC Alpha or VAX machines (Could it have been SCO Unix?)

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.