39

I can seem to run scripts (.sh) with and without them being set as executable. So where exactly this matters?

4 Answers 4

44

Let's say you have the file myscript containing the following:

#!/bin/bash
echo "Hello, World!"

If you make this file executable and run it with ./myscript, then the kernel will see that the first two bytes are #!, which means it's a script-file. The kernel will then use the rest of the line as the interpreter, and pass the file as its first argument. So, it runs:

/bin/bash myscript

and bash reads the file and executes the commands it contains.

Thus, for bash (or whatever interpreter your script requires) to "execute" the script, it only needs to be able to read the file.

So, for scripts, the execute bit just makes it a bit more convenient to execute it. As long as bash is executable, you can always run bash with the script file as argument, or run bash interactively and copy paste the script line by line into your terminal to have the commands executed.

5
  • Thanks for explaining in detail. :) If I understood it right, any user access to bash just needs read access to the script to run it because bash will take the script as input and will only need to read it. I can stop this behaviour by taking the read permission of the script for that user. Right? So when does this executable permission is used & exactly matters?
    – Ashfame
    Feb 10, 2011 at 20:02
  • Yes, if you use "bash myscript" then user only need read access for "myscript" (and of course executable for /bin/bash if bash is there within the path). However, if you make your script executable, things are a bit different. It's true that from the kernel's point of view, it will be "/bin/bash myscript" again if the first line is #!/bin/bash, but to reach that point, first you need to present the script as executable for the user or group. However, that's true if for some user the script is not executable but readable, (s)he can still "run" the script with "bash myscript" ....
    – LGB
    Feb 10, 2011 at 21:40
  • @LGB So that's pretty much useless. Good thing is to cut the read permission away from a user for that script. Right?
    – Ashfame
    Feb 10, 2011 at 22:08
  • @Ashfame: I would say useful rather than useless. The execute bit on regular files is not (and never was intended to be) used for limiting access. It seems like you're expecting that from it. If you have a binary executable, you must have execute permission on it to run it. However, if you have read access to it, you can always copy the file to your own home directory, in which case the copy will be owned by you, so you can add execute permission to it ... and run it. For directories though, it has a bit different purpose. See mywiki.wooledge.org/Permissions
    – geirha
    Feb 10, 2011 at 22:21
  • 2
    What should I use instead of /bin/bash if I don't know the correct interpreter? Is there a command that runs the script according to the shebang line?
    – Aivar
    Nov 17, 2016 at 8:51
19

Make sure you are not confusing "executing the shell script" with "run a shell script using sh".

This will not be affected by file permissions on file.sh:

sh file.sh

You are executing sh (which resolves to the program /bin/sh), which reads file.sh and executes it's code.

File permissions will have effect if you really execute the script itself :

./file.sh

Note that file permissions are not supported by non-Linux filesystems, like FAT. So even if you run chmod -x file.sh, the file will still have it's former permissions.

Execute permission is enforced by the filesystem. But programs can "execute" the code too by reading the file contents, which bypasses filesystem permissions on "execute".

6
  • I understand your point. But then is it for group or world or both?
    – Ashfame
    Feb 10, 2011 at 19:04
  • @Ashfame If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis. But even people without execute permission can execute it by calling a different program (like bash) to do the execution - to block that you would have to take away their read permission as well. Feb 10, 2011 at 19:37
  • If you set the executable permission, the script can be run directly by users who have that permission - whether they have it on a group, world or owner basis But how the permission is granted to different users by checking the executable permission? And I got your second point. You mean taking away their read permission of the script so that they can't even process it through bash. Right?
    – Ashfame
    Feb 10, 2011 at 19:58
  • @Ashfame On the read permission point, yes. On how, you would call something like sudo chmod g+x myfile.sh in the terminal to add execute permissions for the file's group. See File permissions tutorial. To manage permissions for several users simultaneously, you would use groups, see for example Managing groups. Feb 10, 2011 at 21:43
  • what i meant was when we add the execuatable permission in GUI, then its for whom? owner/group/world?
    – Ashfame
    Feb 10, 2011 at 21:57
3

The exec syscall of the Linux kernel fails with EACCES if the file is not executable

While you can do sh myprog.sh (which just reads the files and interprets is), trying to run the program as ./myprog.sh cannot work, since when you do that:

This can be verified with main.c:

#define _XOPEN_SOURCE 700
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    char *argv[] = {"myprog", NULL};
    char *envp[] = {NULL};
    int ret;
    ret = execve("myprog.sh", argv, envp);
    perror("execve");
    printf("%d\n", errno);
    printf("%d\n", EACCES);
}

and myprog.sh:

#!/bin/sh
echo worked

If myprog.sh is not executable, main fails with:

execve: Permission denied
13
13

Tested in Ubuntu 17.10, gcc -std=c99.

POSIX 7 mentions that at:

The exec functions, except for fexecve(), shall fail if:

[EACCES] Search permission is denied for a directory listed in the new process image file's path prefix, or the new process image file denies execution permission.

Further rationale can be found at: https://security.stackexchange.com/questions/66550/unix-execute-permission-can-be-easily-bypassed-is-it-superfluous-or-whats-the

1

Don't think of it in the way that. Can I execute this file? Think of it in the way that: Who can execute this file?

If the computer is yours and the file is yours I am sure you can execute it. You might want to look further into commands like chmod and chown, and file permissions.

I hope that helps.

1
  • Yes I know about them. That means, I (owner) can always execute it. Right? Then setting a file as executable is for the group or world or both?
    – Ashfame
    Feb 10, 2011 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .