LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-18-2014, 01:43 PM   #1
szejiekoh
LQ Newbie
 
Registered: Jun 2014
Posts: 28

Rep: Reputation: Disabled
why does script need "execute" +x permission ?


Hi all,

To execute a script, there are several ways.

1) providing full path
2) including the path to the script in $PATH
3) bash scriptname.sh
4) source scriptname.sh

Irregardless of where a new shell is spawn to handle the script, why does 1,2 need a +x permission for the script, whereas method 3,4 can execute the script directly ?

Regards,
Noob
 
Old 12-18-2014, 02:10 PM   #2
Ztcoracat
LQ Guru
 
Registered: Dec 2011
Distribution: Slackware
Posts: 7,667
Blog Entries: 10

Rep: Reputation: Disabled
Hi:

This page is a good reference for more information.
http://www.thegeekstuff.com/2010/06/...mand-examples/

Most scripts in general are "Read & Write" only.

One way to check is right click on the script and in "Permissions" you'll find read and right only.

I'm not entirely sure why this has been the default for so long.
If I had to guess it's probably due to administrative privileges (access control)

In others words having the ability to control who may or may not run the script.

The chmod command is pretty handy and has more than one type of flag or flags to accomplish what you need to get done.

HTH
 
Old 12-18-2014, 02:12 PM   #3
suicidaleggroll
LQ Guru
 
Registered: Nov 2010
Location: Colorado
Distribution: OpenSUSE, CentOS
Posts: 5,508

Rep: Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102Reputation: 2102
Because 3 and 4 are not spawning a subshell and executing the script, they're parsing the file and running each of the lines in your shell as if you had typed them on the command line, just like if you opened up the file in a text editor, copied all of the lines, and then pasted them in your shell.
 
Old 12-18-2014, 02:23 PM   #4
genss
Member
 
Registered: Nov 2013
Posts: 739

Rep: Reputation: Disabled
because the #! at the start of a file means "execute by executing the file that follows #! with this file as its parameter"
that is kernels behavior

in other words "#!" is a "magic number" and a script is a program that executes in an interpreter (same for perl, python etc.)

more on that http://en.wikipedia.org/wiki/Shebang_%28Unix%29
and on the magic numbers that define file types http://en.wikipedia.org/wiki/Magic_n...mbers_in_files

edit: forgot to note
then executing a script with ./ or it's full path, it is sent directly to the kernel to be executed

Last edited by genss; 12-18-2014 at 02:35 PM.
 
Old 12-18-2014, 11:41 PM   #5
AnanthaP
Member
 
Registered: Jul 2004
Location: Chennai, India
Distribution: UBUNTU 5.10 since Jul-18,2006 on Intel 820 DC
Posts: 842

Rep: Reputation: 201Reputation: 201Reputation: 201
Actually even if you don't start it with #!, it will execute in option 3 (and maybe 4 - never used it). It is a property of the bash "command" that after all arguments are parsed, remaining args are assumed to be script files and executed. So even though it doesn't have the execute permission, it will execute as an argument to the `bash` command.

Strictly speaking it (#!) is only needed when you want to explicitly specify which program is to be used to interpret the commands in the script file. BUT, within the script, as part of the #! line, you have to anyway specify the full path eg. /bin/bash /bin/perl and so on.

Conclusion: path is needed in most cases. As an argument to bash, the script probably works only from the `pwd` (never checked it out).

OK

Last edited by AnanthaP; 12-19-2014 at 12:04 AM.
 
Old 12-19-2014, 12:07 AM   #6
szejiekoh
LQ Newbie
 
Registered: Jun 2014
Posts: 28

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by suicidaleggroll View Post
Because 3 and 4 are not spawning a subshell and executing the script, they're parsing the file and running each of the lines in your shell as if you had typed them on the command line, just like if you opened up the file in a text editor, copied all of the lines, and then pasted them in your shell.
Dear all,

Thanks for replying.
In another word, it is because i am not directly running the script with option 1 and 2. A child shell is spawned to handle to the script.

But why ? Why does the shell need to have +x on the script in order to interpret it ? Can't it just do the same like its parent shell ?

Regards,
Noob
 
Old 12-19-2014, 12:14 AM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,702

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
It is a security feature.

By not making every file automatically executable it permits the separation of data from programs.

It also happens to defeat most virus vulnerabilities.
 
Old 12-19-2014, 04:09 AM   #8
AnanthaP
Member
 
Registered: Jul 2004
Location: Chennai, India
Distribution: UBUNTU 5.10 since Jul-18,2006 on Intel 820 DC
Posts: 842

Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
But why ? Why does the shell need to have +x on the script in order to interpret it ? Can't it just do the same like its parent shell ?
It is not to interpret it. The +x makes it an executable. If and only if this +x is on, will the script file be executed. Next, since the file is a script file, the shell interprets the contents as a script (bash command, perl commands and so on). Were it to have been a compiled executable, it would execute it.

SO 3 SEQUENCED STEPS.
(1) Use the full, relative path or entries in the $PATH variable to locate the program to be executed.
(2) If the located program has +x attribute, it can be executed. Else it will fail to execute.
The step below applies only if step (2) is successful.
(3) Now if it is a script, then depending on the directive (#! /fullpath/program) it executes the appropriate program like bash, awk, shell etc). If it is not a script but a compiled program, it will execute it according to the magic number.


The spawned shell doesn't have the same contents of $PATH as in the parent.

Quote:
In another word, it is because i am not directly running the script with option 1 and 2. A child shell is spawned to handle to the script.
In options 1 and 2, the current shell is in fact directly running the script. Even in these options, unless the script or program has the +x attribute, it won't run. You can verify this easily. Just compile a small c program. Rename a.out. Remove the +x attribute. It won't run in the shell.
BEING AVAILABLE IN THE $PATH LIST OF DIRECTORIES OR POINTED TO BY GIVING THE PATH WONT WORK IF THE PROGRAM (SCRIPT OR COMPILED) DOESN'T HAVE THE +x ATTRIBUTE.

ok
 
Old 12-20-2014, 12:00 AM   #9
veerain
Senior Member
 
Registered: Mar 2005
Location: Earth bound to Helios
Distribution: Custom
Posts: 2,524

Rep: Reputation: 319Reputation: 319Reputation: 319Reputation: 319
Any file which is to execute needs r+x permission. E.g. Change permissions of /bin/ls to just rw and you will not be able to list files with this command or in other words execute /bin/ls command.

So you want a file to execute you have to set it to r+x permission.

Regarding 3, and 4 the files are bash shell scripts and they are interpreted with /bin/bash which is set r+x.

While 1 and 2 are also bash shell scripts and they can still be executed as bash shell scripts as in 3 and 4.

But If you want to execute 1 and 2 by themselves then you need r+x permissions.

In 1 and 2 the first line would be

#!/bin/bash

or

#!/usr/bin/bash

The kernel when it executes a file with r+x permissions and line like these; it runs the following lines with the command in the first line.

That's all!
 
Old 12-20-2014, 01:42 PM   #10
szejiekoh
LQ Newbie
 
Registered: Jun 2014
Posts: 28

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by AnanthaP View Post
It is not to interpret it. The +x makes it an executable. If and only if this +x is on, will the script file be executed. Next, since the file is a script file, the shell interprets the contents as a script (bash command, perl commands and so on). Were it to have been a compiled executable, it would execute it.

SO 3 SEQUENCED STEPS.
(1) Use the full, relative path or entries in the $PATH variable to locate the program to be executed.
(2) If the located program has +x attribute, it can be executed. Else it will fail to execute.
The step below applies only if step (2) is successful.
(3) Now if it is a script, then depending on the directive (#! /fullpath/program) it executes the appropriate program like bash, awk, shell etc). If it is not a script but a compiled program, it will execute it according to the magic number.


The spawned shell doesn't have the same contents of $PATH as in the parent.

In options 1 and 2, the current shell is in fact directly running the script. Even in these options, unless the script or program has the +x attribute, it won't run. You can verify this easily. Just compile a small c program. Rename a.out. Remove the +x attribute. It won't run in the shell.
BEING AVAILABLE IN THE $PATH LIST OF DIRECTORIES OR POINTED TO BY GIVING THE PATH WONT WORK IF THE PROGRAM (SCRIPT OR COMPILED) DOESN'T HAVE THE +x ATTRIBUTE.

ok

Hi Ananthap,

Thanks for the detailed explanation. But what i am asking is

- why does 1 and 2 need a +x permission but directly bashing or sourcing the script doesn't need a +x on the script ?
- if they reason is because 3 and 4 is directly parsing the script (as explained by suicidaleggroll, why can't 1 and 2 just do the same ?

The answer given by jpollard is due to security reasons.

Regards,
Noob
 
Old 12-20-2014, 06:01 PM   #11
antiX-Dave
LQ Newbie
 
Registered: Dec 2013
Distribution: antiX
Posts: 22

Rep: Reputation: Disabled
Inherently this is because pid #1 wishes to see a execute parameter (for security) before it will allow any other program to run.

Quote:
Originally Posted by szejiekoh View Post
- why does 1 and 2 need a +x permission but directly bashing or sourcing the script doesn't need a +x on the script ?
So....
This is because in options 1 and 2 you are trying to run the script standalone, branched (in some way,shape, or form) from "pid #1".
The shell (typically bash) is generally the file /bin/bash which is an interpreting program already running standalone, called / branched from "pid #1". Therefor "The Shell" is running as options 1 or 2 with the much needed execute permission to satisfy the grandparent of all processes (pid #1).
Take away the +x for "The Shell" and you will no longer have a running interpreter in standalone because "pid #1" will not allow it.

Quote:
Originally Posted by szejiekoh View Post
- if they reason is because 3 and 4 is directly parsing the script (as explained by suicidaleggroll, why can't 1 and 2 just do the same ?
Options 3 and 4 are relying on "The Shell" which grandfather process "pid #1" has already allowed to run. Therefor (speaking simplified) "pid #1" allows "The Shell" to operate based on the +x attribute of "The Shell", then "The Shell" allows any file to run when sourced or called with itself based on if it can interpret the file or not. If it cannot interpret the file, it relies on the first head line, "#!/usr/bin/env python" then executes "/usr/bin/env" in option number 1 or 2. "/usr/bin/env" fills the need of the great "pid #1" (it has the +x attribute) and therefor is allowed to run. You have essentially switched to "The New Shell" for the script. Now "The New Shell" runs and if it can interpret said file than the program will run.

Best Visual of this I think it
pstree
or
ps -jfx
 
Old 12-20-2014, 06:40 PM   #12
AnanthaP
Member
 
Registered: Jul 2004
Location: Chennai, India
Distribution: UBUNTU 5.10 since Jul-18,2006 on Intel 820 DC
Posts: 842

Rep: Reputation: 201Reputation: 201Reputation: 201
Options 1 and 2 are executed in your current shell and so since they are supposed to be programs (first option on the command line), a +x attribute is needed to execute the program - your case a script.

As to why option 3 desn't require the +x attrbute is because you are actually executingthe "bash" program nd your script isjust an argument to the bash programme.

Ok

Last edited by AnanthaP; 12-20-2014 at 06:49 PM.
 
1 members found this post helpful.
Old 12-21-2014, 07:24 AM   #13
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,702

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
Pid 1 doesn't even come into it.

The kernel is the one that identifies files to be executed, evaluated based on access permissions.

init will not execute either if it doesn't have the execute permission - you get a "no init" failure and the system halts.

It is a security function.

A file may be executed if:

1) the running process has the same UID as the file, AND
1a) the file permissions grant the owner execute permission.
2) OR the running process has the same GID as the file AND
2a) the file permissions grant the group execute permission.
3) OR the file grant the world execute permission.

Evaluation of permissions is done by a single function, and it makes sense to use that SAME function for user, group, and world. (btw, the kernel function is "open_exec")

Now once the file has been identified as something to execute, the kernel then

1) reads the first block to identify the "magic numbers". If that magic number is "#!", then the actual executable file reference is parsed (including parameters, which gets the current parameter list appended), and the check is repeated... and this step gets repeated until an executable binary is located.

2) The located binary is loaded and is given a new process structure with a copy of the current environment, a copy of the list of parameters, and gets entered in the run queue.

I have glossed over the details, but you can find it at http://lxr.free-electrons.com/, which has a cross referenced copy of the kernel source and trace it yourselves. The full details will include checking for access control lists, and mandatory access controls if the kernel is configured for it.
 
Old 12-21-2014, 08:08 AM   #14
antiX-Dave
LQ Newbie
 
Registered: Dec 2013
Distribution: antiX
Posts: 22

Rep: Reputation: Disabled
Well your explanation makes much more programing sense.
I will recant my textbook explanation (rewritten in my words) and mark it down as the 4th major error.

Sorry for spreading more false information szejiekoh.
And thank you jpollard for the more correct explanation.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ns: stop: couldn't execute "nam": permission denied while executing "exec nam Niraj Mishra Linux - Newbie 1 11-08-2014 06:57 AM
Usage of "-f" option of grep in a script results in "Permission Denied" error zaayu87 Linux - Newbie 3 07-25-2013 12:45 PM
how to fix "sudo: unable to execute /bin/ls: Permission denied"? nagendrar Linux - Newbie 12 09-14-2012 06:55 AM
Failed to execute child process "ooffice" (Permission denied) Mol_Bolom Linux - Software 2 03-11-2009 04:23 PM
can't execute c++ binaries, "permission denied"... even though permission is 777 SerfurJ Programming 14 02-20-2009 04:50 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 01:33 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration