Difference between './file' and 'sh file'

Question

On macOS, in the zsh terminal, I ran the following commands:

cd /tmp
mkdir newdir
cd newdir
touch file1
./file1

The last command returned zsh: permission denied: ./file1

But running sh file1 executed the file with no errors.

I've read about how running sh filename executes the file using the sh interpreter explicitly. The sh interpreter has additional permissions that allow it to run file1.

However, I also read that ./file1 executes file1 using the default interpreter, in my case zsh. So I tried to run

zsh file1

But this also executed the file without errors.

The question:

Why doesn't the interactive shell have permission to run the file, but at the same time has permission to execute using the interpreters sh, bash, zsh?

Additionally, looking at the permissions of sh, bash, zsh in the \bin directory shows that the other group has execute permissions on them:

-rwxr-xr-x  1 root  wheel   1.3M Sep 16 16:28 zsh
-r-xr-xr-x  1 root  wheel   1.2M Sep 16 16:28 bash
-rwxr-xr-x  1 root  wheel   131K Sep 16 16:28 sh

Doesn't this mean any user can run any file using the interpreters which possess additional permissions?

Answer 1

The sh interpreter has additional permissions that allow it to run file1.

No, it doesn't.

So why doesn't the interactive shell have permission to run the file, but at the same time has permission to execute using the interpreters sh, bash, zsh?

Interpreters don't actually "run" or "execute" the script file at all, as far as the OS is concerned. They only read it – and then they do stuff according to what's in the file. (Hence the name 'interpreter'.)

So when you do sh myfile, what happens is that 'sh' reads a line, calls chdir(); reads a line, spawns /bin/mkdir; reads a line, calls chdir() again; reads a line, spawns /bin/touch; … – the OS doesn't really know or care that those actions are done on behalf of a script.

(On systems such as macOS or Windows, the interpreter might deliberately inform the OS that it's processing a certain script, for auditing or security policy purposes, but it doesn't have to.)

For scripts, the 'execute' permission is mostly just there for convenience (and integration – together with #!/bin/xxx headers it allows scripts to look and act like standard executables), not as any kind of security measure.

Doesn't this mean any user can run any file using the interpreters which possess additional permissions?

Any user can "run" any file using any interpreter, as long as the interpreter itself is executable.

That is, the '+x' permission on /bin/zsh only lets the user execute /bin/zsh itself – it doesn't grant zsh any special rights beyond what the user already has.

(There are ways to grant an executable some special rights, such as the 'setuid' flag or Linux "file capabilities" – making an interpreter 'setuid' would then grant the same rights to any script in interprets – but that's normally not done.)