Dlaczego źródło Basha nie potrzebuje bitu wykonania?

Dzięki Bash'owi sourcemożliwe jest wykonanie skryptu bez zestawu bitów wykonania. Jest to udokumentowane i oczekiwane zachowanie, ale czy nie jest to sprzeczne z użyciem bitu wykonania?

Wiem, że sourceto nie tworzy podpowłoki.

Bash jest tłumaczem; przyjmuje dane wejściowe i robi wszystko, co chce. Nie musi zwracać uwagi na wykonywalny bit. W rzeczywistości Bash jest przenośny i może działać na systemach operacyjnych i systemach plików, które nie mają pojęcia o bicie wykonywalnym.

Bitem wykonywalnym zależy na jądrze systemu operacyjnego. Kiedy jądro Linux wykonuje exec, na przykład, sprawdza, czy system plików nie jest zamontowany z noexecopcją, sprawdza bit wykonywalny pliku programu i egzekwuje wszelkie wymagania nałożone przez moduły bezpieczeństwa (takie jak SELinux lub AppArmor).

Zauważ, że wykonywalny bit jest raczej dyskrecjonalnym rodzajem kontroli. Na przykład w systemie Linux x86-64 można pominąć weryfikację bitu wykonywalnego przez jądro, jawnie wywołując /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2jako interpreter :

cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls

Jest to nieco analogiczne do pozyskiwania kodu źródłowego Bash w Bash, z wyjątkiem tego, że ld.sojest to interpreter, a kod, który wykonuje, jest kodem maszynowym w formacie ELF.

sourcelub równoważna, ale standardowa kropka. nie wykonuje skryptu, ale odczytuje polecenia z pliku skryptu, a następnie wykonuje je wiersz po wierszu w bieżącym środowisku powłoki.

Nie ma nic przeciwko używaniu bit wykonania, ponieważ powłoka tylko trzeba czytać uprawnienia do odczytu zawartości pliku.

Bit wykonania jest wymagany tylko po uruchomieniu skryptu. Tutaj powłoka uruchomi fork()nowy proces, a następnie użyje execve()funkcji do utworzenia nowego obrazu procesu ze skryptu, który musi być zwykłym plikiem wykonywalnym.

Bity wykonywalne (w przeciwieństwie do pozostałych) w plikach nonsetuid i nonsetguid nie stanowią większego mechanizmu bezpieczeństwa. Wszystko, co możesz przeczytać, możesz uruchomić pośrednio, a Linux pozwoli ci pośrednio przeczytać wszystko, co możesz uruchomić, ale nie bezpośrednio przeczytać (to powinno wystarczyć, aby wykopać dziurę w koncepcji nie ustawionego (g) uid x-bit będącego pomiar bezpieczeństwa).

Jest to bardziej wygoda: pozwól systemowi uruchomić go dla mnie bezpośrednio, jeśli bit jest ustawiony, w przeciwnym razie muszę to zrobić pośrednio ( bash the_script;lub trochę włamania, aby uzyskać obraz pamięci wykonywalnego pliku bez uprawnień do odczytu ).

Możesz ustawić tę opcję dla wygody, jeśli zamierzasz korzystać zarówno ze źródła, jak i ze swojego źródła.

Najwyraźniej jednak wielu implementatorów bibliotek współużytkowanych podziela twoje zdanie, w związku z czym wiele systemów wymaga, aby biblioteki współdzielone, które są zasadniczo natywnym odpowiednikiem powłokowych powłok, były oznaczone jako pliki wykonywalne, aby były użyteczne. Zobacz: Dlaczego biblioteki współdzielone są wykonywalne? .

To dobre pytanie! Unix używa bitu wykonywalnego do rozróżnienia programów i danych. System operacyjny nie wymaga bitu wykonania, ponieważ skrypt źródłowy nie jest przekazywany do systemu operacyjnego w celu wykonania jako nowy proces. Ale powłoka traktuje skrypt $PATHźródłowy jako program i szuka pliku, który chcesz pobrać. Tak więc sama powłoka mogła wymagać pozwolenia na wykonanie plików źródłowych; ale tak nie było.

Pytanie musiało pojawić się dawno temu. Projekt powłoki Bourne'a był wynikiem „długiej sekwencji modyfikacji, dialogu, dyskusji” wśród mieszkańców Bell Labs, a wiele decyzji projektowych było dyskutowanych przez SR Bourne'a i innych na przestrzeni lat. Niestety, moje szybkie spojrzenie nie znalazło żadnej dyskusji na temat funkcji źródłowej (w mojej obronie trudno go znaleźć w Google). Znalazłem to, że „.” polecenie nie pojawia się we wczesnym wprowadzeniu do powłoki przez samego Bourne'a, ale jest obecne w bardziej dojrzałej wersji 7 .

Brak autorytetu, oto moja własna interpretacja:

1. .Poleceń, aka source, jest włączenie efektów tekstowych (jak #includew preprocesora C) do kodu źródłowego skryptu wykonującego lub sesji interaktywnej. Jako taki, dołączony plik prawdopodobnie nie jest „wykonywany”.

2. Filozofią Uniksa zawsze było dawanie programistom wystarczającej ilości liny do powieszenia się. Po prostu przeszkadza zbyt duże trzymanie się za ręce i arbitralne ograniczenia. Dopiero niedawno niektóre dystrybucje rm -r /odmawiają robienia tego, o co prosisz. (Polecenie to mówi rmsię usunąć wszystko na komputerze. Nie próbuj go jako root! Albo jeszcze lepiej, a nie w ogóle). Tak więc, może Bourne przy al. właśnie zdecydowałem, że przy próbie źródła pliku zakłada się, że wiesz, co robisz. Pozwala to również uniknąć niepotrzebnej pracy, a cykle miały wówczas duże znaczenie.

Jeśli chodzi o system operacyjny, plik zawierający skrypt powłoki to tylko dane. Jeśli przekażesz nazwę takiego pliku danych do sourcepolecenia lub przekażesz go w wierszu polecenia do wywołania powłoki bash, wszystko, co widzi system operacyjny, to ciąg znaków, który pokrywa się z nazwą pliku zawierającego dane.

Jak w takim przypadku bit wykonawczy byłby w ogóle istotny?

To rozróżnienie jest ważne, ponieważ możesz mieć plik poleceń powłoki, który nie jest użyteczny jako plik wykonywalny, ale jest przydatny tylko po uzyskaniu. W przypadku tego pliku można wyłączyć bit wykonywania, a wtedy dostęp do niego nigdy nie będzie możliwy, chyba że zostanie to jawnie wykonane w poleceniu źródłowym. Powodem tego jest efekt uboczny powłoki, z której jest uruchamiany. Na konkretny przykład mam skrypt o nazwie fix_path, który przegląda i modyfikuje ścieżkę.

Na wszelki wypadek, gdy ktoś jest zainteresowany dalszymi badaniami i / lub wyjaśnieniami: W powłoce prawie zgodnej z POSIX zaimplementowanej jakiś czas temu wewnętrzne funkcje funkcji „exec_program ()” i „wbudowane_źródło ()” są bardzo przykładowe. W tych funkcjach widać dokładnie, jaka jest między nimi różnica:

https://github.com/rsenn/shish/blob/master/src/builtin/builtin_source.c

https://github.com/rsenn/shish/blob/master/src/exec/exec_program.c

w zasadzie pozyskiwanie może być postrzegane jako powłoka tymczasowo przekierowująca swój wewnętrzny deskryptor pliku, z którego analizuje skrypt powłoki (terminal w trybie interaktywnym). więc jest bardzo podobny do innych przekierowań takich jak <input_file.txti, >>append_to_something.lista one tylko muszą otwierać i zamykać pliki.

więc wykonanie jest obsługiwane przez execve()wywołanie systemowe, dla którego bit wykonania jest obowiązkowy.

Pamiętam, że widziałem niektóre systemy, które pozwalają na uruchamianie plików binarnych ELF / a.out, ale poprzez wykonanie „/lib/ld-dynamic-linker.so” i programu binarnego (bez bitu exec) jako pierwszego argumentu. Myślę, że tak było na niektórych komputerach DEC Alpha lub VAX (czy to mógł być SCO Unix?)

Inny punkt widzenia:

Skrypt źródłowy zasadniczo składa się z wbudowanych powłok i wywołań programów. Wbudowane powłoki (wraz z sourcenimi) są częściami powłoki i powłoka musi być wykonywalna w pierwszej kolejności. Każdy wywoływany program (czyli ELF, inny skrypt z shebang, cokolwiek) musi mieć ustawiony bit wykonania, w przeciwnym razie nie będzie działał.

Dlatego nie jest to sprzeczne z użyciem bitu wykonania, ponieważ nic bez bitu wykonania nie będzie działać. Sprawdzanie poprawności nie występuje dla całego skryptu źródłowego; jest wykonywany dla każdej części osobno, ale tak jest.