Mdthbs

Sparring against two opponents test

Dangerous workplace travelling

All of my Firefox add-ons been disabled suddenly, how can I re-enable them?

Should I simplify my writing in a foreign country?

Why did WWI include Japan?

Is there an age requirement to play in Adventurers League?

It isn’t that you must stop now

What Kind of Wooden Beam is this

How can Internet speed be 10 times slower without a router than when using the same connection with a router?

Clarification of algebra in moment generating functions

What happens if I accidentally leave an app running and click "Install Now" in Software Updater?

What is the closest airport to the center of the city it serves?

Some Russian letters overlap the next line of text when used in drop caps

GitLab account hacked and repo wiped

Is 'contemporary' ambiguous and if so is there a better word?

What does にとり mean？

Is it normal for gliders not to have attitude indicators?

How to deal with employer who keeps me at work after working hours

Where are the "shires" in the UK?

Constitutional limitation of criminalizing behavior in US law?

Krull dimension of the ring of global sections

Is the book wrong about the Nyquist Sampling Criterion?

Who filmed the Apollo 11 trans-lunar injection?

How to properly store the current value of int variable into a token list?

Who runs the interpreter for files that are execute-only?

Why, by design, are group permissions ignored for the owner of a file?Given the permissions, owner and group of a file, what's the algorithm that determines whether a given user can read/write/execute a file?If a user can only read and write files, is that sufficient to prevent execution?Launching zypper command with root privilegeIs a process with effective or real uid being root still subject to permission bits of a file when accessing the file?su - root failed with error “Cannot execute username: No such file or directory”Is root a privileged user in unix?Is a php file with SGID bit and read-only & execute a security problem?If rc.local is run as root why can't it touch a fileCan still cat/tail/head/etc. a file without the read permission

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

0

If the current user only has execute (--x) permissions on a file, under which user does the interpreter (specified by #!/path/to/interpreter at the beginning of the file) run?

It couldn't be the current user, because he doesn't have permission to read the file. It couldn't be root, because then arbitrary code included in the interpreter would gain root access.

As which user, then, does the interpreter process run?

Edit: I think my question assumes that the file has already been read enough to know which interpreter it specifies, when in reality it wouldn't get that far. The current shell (usually b/a/sh) interpreting the command to execute the target file would attempt to read it, and fail.

permissions process root interpreter

share|improve this question

edited 1 hour ago

ATLief

asked 1 hour ago

ATLiefATLief

185

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Current user. Executing a file doesn't really need read permission, as long as the interpreter support that. Although most script language doesn't support that, please clarify what interpreter you're using
  
  – 炸鱼薯条德里克
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @炸鱼薯条德里克 it doesn't matter what interpreter it is. if it cannot read the file, it cannot "interpret" it either.
  
  – mosvy
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  If the interpreter is setuid root, it'll be able to read the file. As the other commenter posted, it may help to know what the concrete situation is.
  
  – ctt
  1 hour ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @ctt do you know of any interpreter which is installed as setuid or cap_dac_override+ep by default?
  
  – mosvy
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  No. bash will first try to run an executable script via the execve system call (which does not care about its reading perms), and only if that fails with ENOEXEC it will try to read it itself and run it as a script. Your assumptions from the Edit: part are wrong.
  
  – mosvy
  56 mins ago
  
  
  

  
  
  
  

 | 
show 3 more comments

0

If the current user only has execute (--x) permissions on a file, under which user does the interpreter (specified by #!/path/to/interpreter at the beginning of the file) run?

It couldn't be the current user, because he doesn't have permission to read the file. It couldn't be root, because then arbitrary code included in the interpreter would gain root access.

As which user, then, does the interpreter process run?

Edit: I think my question assumes that the file has already been read enough to know which interpreter it specifies, when in reality it wouldn't get that far. The current shell (usually b/a/sh) interpreting the command to execute the target file would attempt to read it, and fail.

permissions process root interpreter

share|improve this question

edited 1 hour ago

ATLief

asked 1 hour ago

ATLiefATLief

185

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Current user. Executing a file doesn't really need read permission, as long as the interpreter support that. Although most script language doesn't support that, please clarify what interpreter you're using
  
  – 炸鱼薯条德里克
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @炸鱼薯条德里克 it doesn't matter what interpreter it is. if it cannot read the file, it cannot "interpret" it either.
  
  – mosvy
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  If the interpreter is setuid root, it'll be able to read the file. As the other commenter posted, it may help to know what the concrete situation is.
  
  – ctt
  1 hour ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @ctt do you know of any interpreter which is installed as setuid or cap_dac_override+ep by default?
  
  – mosvy
  1 hour ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  No. bash will first try to run an executable script via the execve system call (which does not care about its reading perms), and only if that fails with ENOEXEC it will try to read it itself and run it as a script. Your assumptions from the Edit: part are wrong.
  
  – mosvy
  56 mins ago
  
  
  

  
  
  
  

 | 
show 3 more comments

If the current user only has execute (--x) permissions on a file, under which user does the interpreter (specified by #!/path/to/interpreter at the beginning of the file) run?

It couldn't be the current user, because he doesn't have permission to read the file. It couldn't be root, because then arbitrary code included in the interpreter would gain root access.

As which user, then, does the interpreter process run?

Edit: I think my question assumes that the file has already been read enough to know which interpreter it specifies, when in reality it wouldn't get that far. The current shell (usually b/a/sh) interpreting the command to execute the target file would attempt to read it, and fail.

permissions process root interpreter

share|improve this question

edited 1 hour ago

ATLief

asked 1 hour ago

ATLiefATLief

185

share|improve this question

edited 1 hour ago

ATLief

asked 1 hour ago

ATLiefATLief

185

share|improve this question

edited 1 hour ago

ATLief

asked 1 hour ago

ATLiefATLief

185

asked 1 hour ago

ATLiefATLief

185

asked 1 hour ago

ATLiefATLief

185

2 Answers
2

active

oldest

votes

0

In general, scripts can not be executed without "r" permission, even if you own the file

$ ls -l tst

---x--x--x 1 sweh sweh 24 May  4 21:22 tst*



$ ./tst

/bin/bash: ./tst: Permission denied



$ sudo cat tst

#!/bin/bash



echo hello

With your edited question.

The #! part of the program is interpreted by the kernel as part of the exec() system call. So to get that far the script doesn't need to be readable.

Effectively what happens, in my example, is that the kernel converts my ./tst into a /bin/bash ./tst call.

This conversion explains why scripts need to have r access to be processed, but the kernel just needs x to determine the interpreter to be used.

share|improve this answer

edited 57 mins ago

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

add a comment | 

0

If the user only has execute permissions on an executable script, then trying to run it will fail, unless the user has the CAP_DAC_OVERRIDE capability (eg. she's root).

$ cat > yup; chmod 100 yup

#! /bin/sh

echo yup

^D

$ ./yup

/bin/sh: 0: Can't open ./yup

The interpreter (whether failing or successful) will always run as the current user.

Executable scripts are different from binaries in the fact that you should always have reading permission if you want to run them. However, notice that they're simply passed as an argument to the interpreter from the shebang line, which may not try to read them at all, but do something completely different:

$ cat > interp; chmod 755 interp

#! /bin/sh

printf 'you said %sn' "$1"

^D

$ cat > script; chmod 100 script

#! ./interp

nothing to see here

^D

$ ./script

you said ./script

share|improve this answer

edited 31 mins ago

answered 1 hour ago

mosvymosvy

11.1k11340

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f517165%2fwho-runs-the-interpreter-for-files-that-are-execute-only%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

0

In general, scripts can not be executed without "r" permission, even if you own the file

$ ls -l tst

---x--x--x 1 sweh sweh 24 May  4 21:22 tst*



$ ./tst

/bin/bash: ./tst: Permission denied



$ sudo cat tst

#!/bin/bash



echo hello

With your edited question.

The #! part of the program is interpreted by the kernel as part of the exec() system call. So to get that far the script doesn't need to be readable.

Effectively what happens, in my example, is that the kernel converts my ./tst into a /bin/bash ./tst call.

This conversion explains why scripts need to have r access to be processed, but the kernel just needs x to determine the interpreter to be used.

share|improve this answer

edited 57 mins ago

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

add a comment | 

0

In general, scripts can not be executed without "r" permission, even if you own the file

$ ls -l tst

---x--x--x 1 sweh sweh 24 May  4 21:22 tst*



$ ./tst

/bin/bash: ./tst: Permission denied



$ sudo cat tst

#!/bin/bash



echo hello

With your edited question.

The #! part of the program is interpreted by the kernel as part of the exec() system call. So to get that far the script doesn't need to be readable.

Effectively what happens, in my example, is that the kernel converts my ./tst into a /bin/bash ./tst call.

This conversion explains why scripts need to have r access to be processed, but the kernel just needs x to determine the interpreter to be used.

share|improve this answer

edited 57 mins ago

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

add a comment | 

In general, scripts can not be executed without "r" permission, even if you own the file

$ ls -l tst

---x--x--x 1 sweh sweh 24 May  4 21:22 tst*



$ ./tst

/bin/bash: ./tst: Permission denied



$ sudo cat tst

#!/bin/bash



echo hello

With your edited question.

The #! part of the program is interpreted by the kernel as part of the exec() system call. So to get that far the script doesn't need to be readable.

Effectively what happens, in my example, is that the kernel converts my ./tst into a /bin/bash ./tst call.

This conversion explains why scripts need to have r access to be processed, but the kernel just needs x to determine the interpreter to be used.

share|improve this answer

edited 57 mins ago

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

$ ls -l tst

---x--x--x 1 sweh sweh 24 May  4 21:22 tst*



$ ./tst

/bin/bash: ./tst: Permission denied



$ sudo cat tst

#!/bin/bash



echo hello

share|improve this answer

edited 57 mins ago

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

answered 1 hour ago

Stephen HarrisStephen Harris

27.7k35483

0

If the user only has execute permissions on an executable script, then trying to run it will fail, unless the user has the CAP_DAC_OVERRIDE capability (eg. she's root).

$ cat > yup; chmod 100 yup

#! /bin/sh

echo yup

^D

$ ./yup

/bin/sh: 0: Can't open ./yup

The interpreter (whether failing or successful) will always run as the current user.

Executable scripts are different from binaries in the fact that you should always have reading permission if you want to run them. However, notice that they're simply passed as an argument to the interpreter from the shebang line, which may not try to read them at all, but do something completely different:

$ cat > interp; chmod 755 interp

#! /bin/sh

printf 'you said %sn' "$1"

^D

$ cat > script; chmod 100 script

#! ./interp

nothing to see here

^D

$ ./script

you said ./script

share|improve this answer

edited 31 mins ago

answered 1 hour ago

mosvymosvy

11.1k11340

add a comment | 

0

If the user only has execute permissions on an executable script, then trying to run it will fail, unless the user has the CAP_DAC_OVERRIDE capability (eg. she's root).

$ cat > yup; chmod 100 yup

#! /bin/sh

echo yup

^D

$ ./yup

/bin/sh: 0: Can't open ./yup

The interpreter (whether failing or successful) will always run as the current user.

Executable scripts are different from binaries in the fact that you should always have reading permission if you want to run them. However, notice that they're simply passed as an argument to the interpreter from the shebang line, which may not try to read them at all, but do something completely different:

$ cat > interp; chmod 755 interp

#! /bin/sh

printf 'you said %sn' "$1"

^D

$ cat > script; chmod 100 script

#! ./interp

nothing to see here

^D

$ ./script

you said ./script

share|improve this answer

edited 31 mins ago

answered 1 hour ago

mosvymosvy

11.1k11340

add a comment | 

If the user only has execute permissions on an executable script, then trying to run it will fail, unless the user has the CAP_DAC_OVERRIDE capability (eg. she's root).

$ cat > yup; chmod 100 yup

#! /bin/sh

echo yup

^D

$ ./yup

/bin/sh: 0: Can't open ./yup

The interpreter (whether failing or successful) will always run as the current user.

Executable scripts are different from binaries in the fact that you should always have reading permission if you want to run them. However, notice that they're simply passed as an argument to the interpreter from the shebang line, which may not try to read them at all, but do something completely different:

$ cat > interp; chmod 755 interp

#! /bin/sh

printf 'you said %sn' "$1"

^D

$ cat > script; chmod 100 script

#! ./interp

nothing to see here

^D

$ ./script

you said ./script

share|improve this answer

edited 31 mins ago

answered 1 hour ago

mosvymosvy

11.1k11340

$ cat > yup; chmod 100 yup

#! /bin/sh

echo yup

^D

$ ./yup

/bin/sh: 0: Can't open ./yup

$ cat > interp; chmod 755 interp

#! /bin/sh

printf 'you said %sn' "$1"

^D

$ cat > script; chmod 100 script

#! ./interp

nothing to see here

^D

$ ./script

you said ./script

share|improve this answer

edited 31 mins ago

answered 1 hour ago

mosvymosvy

11.1k11340

answered 1 hour ago

mosvymosvy

11.1k11340

answered 1 hour ago

mosvymosvy

11.1k11340