6

It's a well-known fact that if one wants to execute a script in shell, then the script needs to have execute permissions:

$ ls -l
total 4
-rw-r--r-- 1 user user 19 Mar 14 01:08 hw
$ ./hw
bash: ./hw: Permission denied
$ /home/user/hw
bash: /home/user/hw: Permission denied
$

However, it is possible to execute this script with bash <scriptname>, sh <scriptname>, etc:

$ bash hw
Hello, World!
$ 

This means that basically one can execute a script file, even if it only has read permissions. This maybe is a silly question, but what is the point of giving execute permissions to a script file? Is it solely because in order for a program to run it needs to have execute permissions, but it actually doesn't add security or any other benefits?

  • Look at it from another view: Why should scripts be handled differently from binary executables? Every benefit the x bit adds to binaries, applies to scripts as well. What good would it do to handle executables differently depending on whether they are binaries or scripts? And of course you can pass any readable file as an argument to an executable. Why introduce special rules to prevent script files from being passed to an interpreter? – Philippos Mar 14 '17 at 7:04
8

Yes, you can use bash /path/to/script, but scripts can have different interpreters. Its possible your script was written to work with ksh, zsh, or maybe even awk or expect. Thus you have to know what interpreter to use to call the script with. By instead making a script with a shebang line (that #!/bin/bash at the top) executable, the user no longer needs to know what interpreter to use. It also allows you to put the script in $PATH and call it like a normal program.

  • 10
    In fact even regular programs can be executed with /lib/ld-linux.so.2 /path/to/executable or /lib64/ld-linux-x86-64.so.2 /path/to/executable even if they don't have the executable bit. – cg909 Mar 14 '17 at 0:07
  • 2
    While everything you say is true, you have not explained the security benefits of the execute bit (i.e. why the system even has an execute bit and requires that it be set). – Kevin Mar 14 '17 at 3:31
  • @Kevin The interpreter, whether it's ksh or ld.so needs to be executable. If there isn't an executable bit then either everything would have to be executable, or nothing. With an executable bit, we can choose what should be executable and what should not be. – Kusalananda Mar 14 '17 at 8:46
  • 2
    @Kevin that's because the execute bit has nothing to do with security. It's for convenience. Everything you can do with an executable file you can also do with a non-executable file, it's just more cumbersome. As Kusalananda pointed out, only the loader needs to be executable. – Patrick Mar 14 '17 at 12:33
2

The security feature lies in the combination with the suid/sgid bit, but read on.

Exec bit alone is now mainly a convenience - it shows which files are meant to be directly executed.

  • when typing commands, files w/o exec are not run in the current dir, if you have "." in your PATH
  • TAB autocompletion can suggest only files w/ exec bit if it sees you are typing a command name
  • users can better see what files are to be executed
  • it tells kernel that the file whose name user typed is a command and the kernel should bother to open it and find out what it's loader/executor is.

But it does not prevent a dedicated user to run the file, as others already shown.

The catch is, that when you can circumvent the (lack of) the exec bit when running the file with an explicit loader, you also do not use its suid/sgid bit, so you do not get elevated privileges.

Let's have in /bin

 -rwsr--r-- root root some_privileged_command

You can execute the command as an unprivileged user with

 $ /lib/ld-linux.so.2 /bin/some_privileged_command

but it will not be executed with root permissions, unlike

 -rwsr-xr-x root root other_privileged_command

that will, if you exec it directly as

 $ /bin/other_privileged_command

That said, it's moot for shebang commands anyways, because they won't be executed with root perms even with suid set - for that, the shell executable itself would need that bit (and it would be really, really bad to do it).

  • The first half of this answer has nothing to do with security. Interaction with $PATH is just convenience, not security. The second half of the answer has nothing to do with scripts. The setuid/setgid bits have no impact on scripts. – Patrick Mar 14 '17 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.