Czy mogę udostępnić plik tylko skryptowi, a nie użytkownikowi?

Mam użytkownika z ograniczonym dostępem do systemu (to znaczy, że nie jest sudoerem); nazwijmy go Bob .

Mam skrypt lub plik binarny, któremu ja, administrator systemu, ufam i nie miałbym problemów z uruchomieniem go jako root; nazwijmy skrypt get-todays-passphrase.sh. Zadaniem tego skryptu jest odczyt danych z „prywatnego” (należącego do użytkownika / grupy innego niż Bob, a nawet root) pliku znajdującego się w pliku /srv/daily-passphrasesi wyprowadzenie z pliku tylko określonej linii: linii odpowiadającej dzisiejszej dacie .

Użytkownicy tacy jak Bob nie mogą poznać jutrzejszego hasła, nawet jeśli jest ono wymienione w pliku. Z tego powodu plik /srv/daily-passphrasesjest chroniony uprawnieniami uniksowymi, więc użytkownicy inni niż root, tacy jak Bob, nie mają bezpośredniego dostępu do pliku. Mogą oni jednak uruchomić get-todays-passphrase.shskrypt w dowolnym momencie, który zwraca „przefiltrowane” dane.

Podsumowując ( wersja TL; DR ):

1. Bob nie może odczytać chronionego pliku
2. Skrypt może odczytać chroniony plik
3. W dowolnym momencie Bob może uruchomić skrypt, który może odczytać plik

Czy można to zrobić w ramach uprawnień do plików Unix? A jeśli Bob uruchomi skrypt, czy skrypt będzie zawsze skazany na działanie z tymi samymi uprawnieniami, co Bob?

Jest to w rzeczywistości powszechne i dość proste. sudopozwala ograniczyć określone aplikacje, które użytkownik może wywoływać. Innymi słowy, nie musisz dawać im wszystkich korzeni ani niczego; możesz dać im sudouprawnienia do uruchomienia określonego polecenia . To jest dokładnie to, czego chcesz i jest to bardzo powszechna praktyka w takich przypadkach, jak pozwalanie użytkownikom na wypychanie repozytoriów Git przez SSH i tym podobne.

Aby to zrobić, wystarczy dodać linię, /etc/sudoersktóra wygląda mniej więcej tak

bob ALL=(root) NOPASSWD: /path/to/command/you/trust

(Ta NOPASSWD:część nie jest wymagana, ale jest bardzo powszechna w tej sytuacji.) W tym momencie bobmożna wywoływać /path/to/command/you/trustprzez sudo, ale nic więcej.

To powiedziawszy, dawanie komuś korzenia - co tu robimy - może nie być tym, czego chcesz. W szczególności, jeśli w twoim skrypcie wystąpiły jakiekolwiek wady, ryzykujesz zrootowaniem twojego urządzenia. Z tego powodu możesz zamiast tego utworzyć użytkownika, który będzie właścicielem pliku specjalnego - powiedzmy specialuser- chownnastępnie plik do niego i /etc/sudoersniech make bobbędzie tym specjalnym użytkownikiem. W takim przypadku dodana linia sudoersbyłaby po prostu

bob ALL=(specialuser) NOPASSWD: /path/to/command/you/trust

Przedmowa:

Jak wskazano w komentarzach i z powodów wyjaśnionych w tej odpowiedzi, jądro Linuksa ignoruje bit setuid / setguid podczas obsługi skryptu. Nie będę powielać odpowiedzi Benjamina ale zamiast zastąpić skrypt z executabe aby moja odpowiedź prawidłowa.

Krótka odpowiedź: użyj setgid

Szczegółowe kroki:

1. Utwórz nową grupę (np. Readpass)
2. Ustaw tę grupę jako właściciela pliku hasła sudo chown :readpass thatfile
3. Spraw, aby plik był czytelny tylko dla jego grupy sudo chmod g=r,o= thatfile
4. Spraw, aby Twój wykonywalny sgid readpass:sudo chmod g+s thatfile

W ten sposób plik wykonywalny będzie działał z uprawnieniami grupy będącej właścicielem, a tym samym będzie mógł odczytać plik.