Могут ли скрипты работать, даже если они не установлены как исполняемые?
Мне кажется, что я могу запускать скрипты (.sh) с и без их установки как исполняемые Так, где именно это имеет значение?
4 ответа
Допустим, у вас есть файл myscript , содержащий следующее:
#!/bin/bash
echo "Hello, World!"
Если вы сделаете этот файл исполняемым и запустите его с помощью ./ myscript , тогда ядро увидит, что первые два байта - это #! , что означает, что это файл сценария. Затем ядро будет использовать оставшуюся часть строки в качестве интерпретатора и передаст файл в качестве первого аргумента. Итак, он запускается:
/bin/bash myscript
и bash читает файл и выполняет содержащиеся в нем команды.
Таким образом, для того, чтобы bash (или любой другой интерпретатор, которого требует ваш скрипт), «выполнял» скрипт, ему нужно только иметь возможность читать файл.
Итак, для скриптов бит выполнения просто делает его выполнение немного более удобным. Пока bash является исполняемым, вы всегда можете запустить bash с файлом сценария в качестве аргумента или запустить bash в интерактивном режиме и скопировать и вставить сценарий построчно в свой терминал, чтобы команды выполнялись.
Системный вызов exec Ядро Linux выдает ошибку EACCES , если файл не является исполняемым
Хотя вы можете выполнить sh myprog.sh (который просто читает файлы и интерпретирует их), пытаясь запустить программу as ./ myprog.sh не может работать, поскольку, когда вы это делаете:
- ваша оболочка Bash на терминале использует системный вызов
execдля./ myprog.sh - shebangs интерпретируются редактируется непосредственно системным вызовом
execядра Linux, как описано на странице https://stackoverflow.com/questions/2429511/why-do-people-write-the-usr-bin-env-python-shebang-on-the-first-line-of-a-pyt / 40938801 # 40938801 - ядро Linux отказывается выполнять файлы без разрешения исполняемого файла
Это может быть проверено с помощью 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);
}
и myprog.sh :
#!/bin/sh
echo worked
Если myprog.sh не исполняется, main не выполняется с:
execve: Permission denied
13
13
Проверено в Ubuntu 17.10, gcc -std = c99 .
POSIX 7 упоминает, что в:
Функции exec, за исключением fexecve (), не работают, если:
[EACCES] В разрешении на поиск отказано для каталога, указанного в префиксе пути к новому файлу образа процесса, или в новом файле образа процесса отказано в разрешении на выполнение.
Дальнейшее обоснование можно найти по адресу: https://security.stackexchange.com/ questions / 66550 / unix-execute-permission-можно-легко-обойти-это-лишнее-или-что-то
Не думайте об этом так. Могу я выполнить этот файл?Подумайте об этом так: Кто может выполнить этот файл?
Если компьютер ваш, а файл ваш, я уверен, что вы сможете его запустить. Возможно, вы захотите подробнее изучить такие команды, как chmod и chown , а также права доступа к файлам.
Надеюсь, это поможет.
Убедитесь, что вы не путаете «выполнение сценария оболочки» с «запуском сценария оболочки с использованием sh».
На это не повлияют права доступа к файлу для file.sh :
sh file.sh
Вы выполняете sh (которая преобразуется в программу / bin / sh ), которая читает file.sh и выполняет свой код .
Права доступа к файлам вступят в силу, если вы действительно выполните сам сценарий :
./file.sh
Обратите внимание, что права доступа к файлам не поддерживаются файловыми системами, отличными от Linux, такими как FAT. Таким образом, даже если вы запустите chmod -x file.sh , файл все равно будет иметь прежние разрешения.
Разрешение на выполнение обеспечивается файловой системой. Но программы также могут «выполнять» код, читая содержимое файла, что обходит разрешения файловой системы на «выполнение».