You are not logged in.
What does it mean when you say that a user has has execute privileges on a file?
Context: I am working my way through the book: Linux Command Line and Shell Scripting Bible and I'm learning about permissions.
test16.sh
#!/bin/bash
echo "Hello, World!"The user (owner) for the following scripts is archie, and the directory where test16.sh is located is included in the $PATH.
$ ls -al test16.sh
-rwx------ 1 archie archie 33 Dec 2 17:46 test16.sh
$ test16.sh
Hello, World!$ chmod u-x test16.sh
$ ls -al test16.sh
-rw------- 1 archie archie 33 Dec 2 17:46 test16.sh
$ test16.sh
bash: /home/archie/.scripts/testing/test16.sh: Permission deniedThis is what I would expect. However...
$ ls -al test16.sh
-rw------- 1 archie archie 33 Dec 2 17:46 test16.sh
$ bash test16.sh
Hello, World!The user, archie, does not have execute privileges on the script, but he can run the script anyway if he specifies that the script is to be run using bash.
The 'execute privilege bit' seems to be some sort of security measure, but it seems to be trivially easy to bypass. This suggests that it is either not very useful, or... I'm missing something very basic.
So... what am I missing?
Cheers,
note: I have read File Permissions and Attributes but I couldn't find anyplace where this was addressed.
Last edited by dakota (2018-12-03 14:02:24)
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
Hello,
The distinction here, the command "bash" has execute permissions and is the parent process running test16.sh. I hope that answers your question.
Regards
Offline
To answer the question in your title:
The execute flag determines whether a respective user can execute, i.e. run a file, if the object is a file, or, if the object is a directory, may navigate into that directory.
As for your problem:
The user is not executing the script in your example. They are executing /use/bin/bash, giving it the script as a parameter.
Inofficial first vice president of the Rust Evangelism Strike Force
Online
Hello,
The distinction here, the command "bash" has execute permissions and is the parent process running test16.sh. I hope that answers your question.
Regards
Indeed it does! Thank you.
To answer the question in your title:
The execute flag determines whether a respective user can execute, i.e. run a file, if the object is a file, or, if the object is a directory, may navigate into that directory.
As for your problem:
The user is not executing the script in your example. They are executing /use/bin/bash, giving it the script as a parameter.
$ ls -al /bin/bash
-rwxr-xr-x 1 root root 866600 Jun 4 01:54 /bin/bashThank you! Very clear.
So, if I had a python script that was not executable, but /usr/bin/python2 was, then the user would not be able to execute the file directly, but they could execute it by passing python the script as a parameter.
$ ls -al /usr/bin/python2
lrwxrwxrwx 1 root root 9 Jun 27 06:05 /usr/bin/python2 -> python2.7Very cool. Thanks to you both!
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
If you could mark it [solved]
Offline
What does it mean when you say that a user has has execute privileges on a file?
Depends on the file. In the context of a scripted interpreter language, like bash, it means the file can be directly executed and the interpreter will be directly retrieved from the script's shebang.
In the context of a binary ELF file, it means the file can be directly executed by mapping the file into memory and handing over control to the executable's interpreter -- which for dynamically linked executables usually means reading the interpreter "ld-linux-x86-64.so.2" from the ELF file format metadata.
In all cases, you can always manually execute the file by first executing the interpreter, then passing the file as a positional argument. Yes, this works for non-executable ELF binaries too.
The 'execute privilege bit' seems to be some sort of security measure, but it seems to be trivially easy to bypass. This suggests that it is either not very useful, or... I'm missing something very basic.
So... what am I missing?
It is not a security measure at all. It's there to prevent you from accidentally trying to load a PDF file as executable code and failing with syntax errors like "cannot execute binary file: Exec format error". This is why there isn't some default state of affairs where you can automatically try to execute any file as a program.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Seem usual, why would it depend on a file?
Depends on the file
Are you trying to clarify the 'shebang' line?
Offline
dakota wrote:What does it mean when you say that a user has has execute privileges on a file?
Depends on the file. In the context of a scripted interpreter language, like bash, it means the file can be directly executed and the interpreter will be directly retrieved from the script's shebang.
In the context of a binary ELF file, it means the file can be directly executed by mapping the file into memory and handing over control to the executable's interpreter -- which for dynamically linked executables usually means reading the interpreter "ld-linux-x86-64.so.2" from the ELF file format metadata.
In all cases, you can always manually execute the file by first executing the interpreter, then passing the file as a positional argument. Yes, this works for non-executable ELF binaries too.
The 'execute privilege bit' seems to be some sort of security measure, but it seems to be trivially easy to bypass. This suggests that it is either not very useful, or... I'm missing something very basic.
So... what am I missing?
It is not a security measure at all. It's there to prevent you from accidentally trying to load a PDF file as executable code and failing with syntax errors like "cannot execute binary file: Exec format error". This is why there isn't some default state of affairs where you can automatically try to execute any file as a program.
Thank you very much.
This is an extremely helpful post. Especially the last part about what I was missing. It is all much clearer now. ![]()
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
Seem usual, why would it depend on a file?
eschwartz wrote:Depends on the file
Are you trying to clarify the 'shebang' line?
Shebang or not a shebang, it's fully valid to set execute permissions on the PDF too -- it just won't do anything. I was attempting to clarify what the execute permissions actually do.
Speaking of which...
@dakota,
As I've mentioned, for any file with execute permissions you can attempt to load it as code. The kernel itself only understands ELF files and files with a shebang comment header indicating an interpreter, but it also comes with a builtin facility called "binfmt_misc" by which you can teach the kernel to dynamically recognize a file's magic number and use a specified interpreter to execute it.
So you could absolutely make PDF an executable filetype, and in fact, you could make it open with your favorite PDF reader too. But that's a pretty bad UI and horribly not configurable, so it's better to stick with existing methods for opening media -- that being XDG mimetypes and the desktop database as used by xdg-open.
In this context, it actually makes sense to have executable Windows .exe files, as a common binfmt_misc configuration involves making such files be executed using WINE.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline