Czy skrypty mogą działać, nawet jeśli nie są ustawione jako pliki wykonywalne?

Mogę wydawać się uruchamiać skrypty (.sh) z ustawieniami plików wykonywalnych i bez nich. Więc gdzie to właściwie ma znaczenie?

Załóżmy, że masz plik myscriptzawierający następujące elementy:

#!/bin/bash
echo "Hello, World!"

Jeśli uczynisz ten plik wykonywalnym i uruchomisz go ./myscript, jądro zobaczy, że pierwsze dwa bajty to #!, co oznacza, że ​​jest to plik skryptowy. Jądro wykorzysta resztę wiersza jako interpreter i przekaże plik jako pierwszy argument. Działa więc:

/bin/bash myscript

a bash czyta plik i wykonuje zawarte w nim polecenia.

Tak więc, aby bash (lub jakikolwiek interpreter wymagany przez twój skrypt) „wykonał” skrypt, musi tylko móc odczytać plik.

W przypadku skryptów bit wykonania po prostu sprawia, że ​​jego wykonanie jest nieco wygodniejsze. Tak długo, jak bash jest wykonywalny, zawsze możesz uruchomić bash z plikiem skryptu jako argumentem lub uruchomić bash interaktywnie i skopiować wklej skrypt wiersz po wierszu do terminala, aby wykonać polecenia.

Upewnij się, że nie mylisz „wykonywania skryptu powłoki” z „uruchom skrypt powłoki za pomocą sh”.

Uprawnienia do plików nie będą miały wpływu na file.sh:

sh file.sh

Wykonujesz sh(co powoduje przejście do programu /bin/sh), który czyta file.shi wykonuje jego kod.

Uprawnienia do plików będą obowiązywać, jeśli naprawdę wykonasz sam skrypt :

./file.sh

Pamiętaj, że uprawnienia do plików nie są obsługiwane przez systemy plików inne niż Linux, takie jak FAT. Więc nawet jeśli uruchomisz chmod -x file.sh, plik nadal będzie miał swoje wcześniejsze uprawnienia.

Uprawnienia do wykonywania są wymuszane przez system plików. Ale programy mogą również „wykonać” kod, odczytując zawartość pliku, co pomija uprawnienia systemu plików podczas „wykonywania”.

Nie myśl o tym w ten sposób. Czy mogę wykonać ten plik? Pomyśl o tym w następujący sposób: Kto może wykonać ten plik?

Jeśli komputer należy do Ciebie, a plik należy do Ciebie, jestem pewien, że możesz go wykonać. Możesz przyjrzeć się bliżej takim poleceniom jak chmod i chown oraz uprawnienia do plików.

Mam nadzieję że to pomogło.

execSyscall jądra Linux nie ze EACCESjeśli plik nie jest wykonywalny

Chociaż możesz to zrobić sh myprog.sh(co tylko czyta pliki i interpretuje), próba uruchomienia programu ./myprog.shjest niemożliwa, ponieważ kiedy to zrobisz:

• twoja powłoka Bash na terminalu używa execwywołania systemowego./myprog.sh
• shebangi są interpretowane bezpośrednio przez execwywołanie systemowe jądra systemu Linux, jak wyjaśniono na stronie : /programming/2429511/why-do-people-write-the-usr-bin-env-python-shebang-on -the-first-line-of-a-pyt / 40938801 # 40938801
• jądro Linuksa odmawia wykonywania plików bez uprawnień wykonywalnych

Można to zweryfikować za pomocą 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);
}

i myprog.sh:

#!/bin/sh
echo worked

Jeśli myprog.shnie jest wykonywalny, mainkończy się niepowodzeniem z:

execve: Permission denied
13
13

Testowane w Ubuntu 17.10, gcc -std=c99.

POSIX 7 wspomina, że ​​w:

Funkcje exec, z wyjątkiem fexecve (), zawiodą, jeśli:

[EACCES] Odmówiono pozwolenia na wyszukiwanie dla katalogu wymienionego w prefiksie ścieżki nowego pliku obrazu procesu lub nowy plik obrazu procesu odmawia pozwolenia na wykonanie.

Dalsze uzasadnienie można znaleźć na stronie : /security/66550/unix-execute-permission-can-be-easily-bypassed-is-it-superfluous-or-whats-the