Skąd system operacyjny wie, że polecenie wymaga sudo?

1. Po uruchomieniu pliku wykonywalnego czasami system operacyjny odmawia zgody na to. Na przykład konieczne będzie uruchomienie make installz prefiksem będącym ścieżką systemową sudo, podczas gdy prefiks będący ścieżką niesystemową nie będzie wymagany sudo. W jaki sposób system operacyjny decyduje, że uruchomienie pliku wykonywalnego wymagałoby więcej uprawnień niż użytkownik, nawet zanim program coś zrobi?
2. Czasami uruchomienie programu nie zostanie pozbawione uprawnień, ale program będzie mógł robić więcej rzeczy, jeśli zostanie uruchomiony sudo. Na przykład, gdy jest uruchomiony duw jakimś katalogu systemowym, tylko przy sudonim będzie mógł uzyskać dostęp do jakiegoś katalogu. Dlaczego system operacyjny nie odmawia zgody na uruchomienie takiego programu lub preferowane jest powiadomienie przyjazne, zanim program będzie mógł działać?
3. Czy to prawda, że ​​zawsze, gdy sudodziała, subędzie działać, a kiedy sudziała, sudobędzie działać? czy z su, użytkownik może zrobić więcej niż z sudo? Jak system operacyjny decyduje, kiedy sudodziała, a kiedy sujest potrzebny?

1. Czasami komunikat „Odmowa zezwolenia” jest spowodowany na przykład uprawnieniami systemu plików odmawiającymi dostępu do zapisu. Plik wykonywalny / narzędzie sprawdza po prostu, czy system plików daje ci wystarczające uprawnienia do robienia tego, co masz zamiar zrobić, i zgłasza błąd, jeśli system plików odmówi. W innym przypadku samo narzędzie sprawdzi identyfikator użytkownika, zanim będzie można go dalej używać.
2. Kiedy uruchamiasz program sudo, uruchamiasz go pod nazwą innego użytkownika. Jeśli ten użytkownik jest w stanie „robić więcej rzeczy” niż twój użytkownik, a sudokonfiguracja pozwala ci robić te rzeczy w imieniu innego użytkownika, wówczas tak, sudopozwoli ci robić więcej rzeczy. Nie jest to jednak konieczne. Jeśli po prostu przyczepność sudona na początku linii poleceń, jesteś rzeczywiście sudoing jak root, więc zwykle jesteś w stanie zrobić coś więcej niż zwykły śmiertelnik.
3. Zdecydowanie nie. Aby go użyć sudo, musisz podać własne hasło użytkownika, a następnie możesz robić pewne rzeczy w imieniu użytkownika docelowego. Aby go użyć su, potrzebujesz hasła użytkownika docelowego, a jeśli go masz, stajesz się użytkownikiem docelowym, jeśli chodzi o system i możesz zrobić wszystko, co użytkownik może zrobić.

Zobacz też

• Dlaczego hasło „sudo” jest inne niż hasło „su root”

Dla celów, które opisałeś, system operacyjny nie decyduje, czy potrzebujesz sudo, aby początkowo uruchomić program. Zamiast tego, po uruchomieniu programu, a następnie próbie zrobienia czegoś, co nie jest dozwolone przez bieżącego użytkownika (takiego jak napisanie pliku w /usr/bincelu zainstalowania nowego polecenia), system operacyjny uniemożliwia dostęp do pliku. Działanie, jakie należy podjąć w tym stanie, zależy od programu; makeprzestaje działać, ale dupo wydrukowaniu wiadomości przechodzi do następnego pliku / katalogu.

suI sudopolecenia są dwa różne sposoby uruchamiania programu z uprawnieniami administratora. Mogą się różnić drobnymi szczegółami, takimi jak zawartość środowiska podczas uruchamiania nowego programu, w zależności od użytych opcji. System operacyjny nie musi decydować, kiedy jeden lub drugi może działać.

sui sudosą programami uprzywilejowanymi. suzmienia (po udanym uwierzytelnieniu) rzeczywisty i skuteczny identyfikator użytkownika i grupy na identyfikator użytkownika su. Tak więc sujest podobny do login. Pamiętaj, że sumożna go zmienić na dowolnego użytkownika, nie tylko root. sudozmienia także rzeczywiste i skuteczne identyfikatory użytkowników i grup. Do tego momentu sui sudosą podobne (ale niezwiązane), poza tym są bardzo różne.

Dzięki sumusisz znać hasło celu, a po uwierzytelnieniu możesz robić, co chcesz jako ten użytkownik. Użycie sumożna ograniczyć, ustawiając SU_WHEEL_ONLYw /etc/login.defs. Jeśli jest ustawiony, tylko użytkownicy w grupie wheelmogą korzystać su, w przeciwnym razie nie jest to ograniczone. Poza tym suwszystko jest albo nic.

sudopod tym względem jest zupełnie inna. Dzięki sudomożesz zdefiniować dość złożone zasady /etc/sudoersdotyczące tego, co może robić sudoer (użytkownik dzwoniący sudo). Na przykład można zdefiniować zasady, w których niektórzy użytkownicy mogą uruchamiać tylko niektóre programy z określonymi uprawnieniami, podczas gdy inni użytkownicy mogą uruchamiać inne programy z innymi uprawnieniami.

Jedną z charakterystycznych cech sudojest to, że można go skonfigurować tak, aby użytkownik musiał uwierzytelnić się własnym hasłem (zamiast hasła celu). W ten sposób sudostał się bardzo popularny wśród administratorów, ponieważ pozwala autoryzować użytkowników do wykonywania tylko określonych uprzywilejowanych operacji bez podawania hasła administratora, a także zyskujesz pewien stopień odpowiedzialności.

tl; dr Access jest określany przez użytkownika, który uruchamia aplikację i sudouruchamia aplikacje jako inny użytkownik.

Pełna wersja:

Skąd system operacyjny wie, że polecenie wymaga sudo?

Nie wie UNIX zarządza uprawnieniami nie na poziomie aplikacji, ale na poziomie systemu plików: użytkownicy mają dostęp do określonych plików. Aplikacje są następnie uruchamiane w imieniu użytkownika - z każdym uruchomionym procesem jest powiązany użytkownik. Ten użytkownik służy do określania uprawnień dla tej aplikacji. Sudo działa, uruchamiając aplikacje w imieniu innego użytkownika (z uprawnieniami powiązanymi z tym innym użytkownikiem), a mianowicie rootadministratora.

Jeśli chodzi o twoje przykłady:

1. Jeśli użytkownik ma dostęp do zapisu do określonego katalogu, może make installdo niego przejść . W przeciwnym razie mogą to rootzrobić - za pomocą sudo.

2. Jeśli nie możesz uzyskać dostępu do plików w katalogu, duuruchomienie dla ciebie również nie może uzyskać do niego dostępu. rootma dostęp do praktycznie każdego pliku, więc sudo du( duuruchamiany w imieniu root) może również uzyskać do nich dostęp.

Czy to prawda, że ​​za każdym razem, gdy sudo działa, su również działa, a ilekroć su działa, sudo również działa?

Tak i nie. Tak, jeśli program jest rzeczywiście działać, powinien zachowywać się tak samo zarówno pod sudoa su. sudoZapewnia jednak bardziej szczegółową kontrolę nad tym, kto może uruchamiać to za pomocą zestawu reguł przechowywanych w /etc/sudoerspliku. sujest prostsze - jeśli znasz hasło użytkownika docelowego, możesz uruchamiać programy w imieniu tego użytkownika.

Ostatnia uwaga: sposób, w jaki aplikacja obsługuje odmowę dostępu (gdy przerywa działanie, ignoruje lub ostrzega użytkownika), zależy od aplikacji.

Nikt jeszcze nie ma ✓, więc ułożyłem odpowiedź, która zawiera wszystko, o czym mogę myśleć.

1 Po uruchomieniu pliku wykonywalnego czasami system operacyjny odmawia zgody na to. Na przykład uruchomienie make install z prefiksem będącym ścieżką systemową będzie wymagało sudo, podczas gdy prefiks będący ścieżką niesystemową nie będzie pytany o sudo. W jaki sposób system operacyjny decyduje, że uruchomienie pliku wykonywalnego wymagałoby więcej uprawnień niż użytkownik, nawet zanim program coś zrobi?

Nie, nie jest to wykonywane po uruchomieniu pliku wykonywalnego. Odbywa się to, gdy plik wykonywalny próbuje coś zrobić.

System operacyjny sprawdzi uprawnienia systemu plików i możliwości (nie są one objęte uprawnieniami systemu plików i obejmują zmniejszenie ładnego poziomu, mknode, niektóre elementy sieciowe niskiego poziomu, zabijanie procesów innych, restart, ustawianie czasu itp.). Jeśli nie masz uprawnień, nie możesz tego zrobić. Root ma pełny zestaw możliwości, w tym CAP_DAC_OVERRIDE (ignorowanie uprawnień do plików).

2 Czasami uruchomienie programu nie będzie pozbawione uprawnień, ale program będzie mógł robić więcej rzeczy, jeśli zostanie uruchomiony z sudo. Na przykład, gdy uruchomisz du w jakimś katalogu systemowym, tylko z sudo będzie mógł uzyskać dostęp do jakiegoś katalogu. Dlaczego system operacyjny nie odmawia zgody na uruchomienie takiego programu lub preferowane jest powiadomienie przyjazne, zanim program będzie mógł działać?

System operacyjny nie może wiedzieć, co zrobi program. Tak więc program powinien sprawdzić uprawnienia przed uruchomieniem i zdecydować, co zrobić. Nie musi tego jednak robić.

Uwaga: na Androidzie jest manifest, w którym aplikacja deklaruje, jakich uprawnień może użyć. System operacyjny zabije każdą aplikację, która próbuje użyć przywileju, którego nie deklaruje, a system operacyjny nie zawsze gwarantuje, że przywilej ten może zostać uznany. np. dostęp do sieci może być niedostępny.

2 Czy to prawda, że ​​za każdym razem, gdy sudo działa, su również działa, a ilekroć su działa, sudo również działa? czy z su użytkownik może zrobić więcej niż z sudo? Jak system operacyjny decyduje, kiedy sudo działa i kiedy su jest potrzebne?

sudoi z sugrubsza pobierajcie próbki. Niektóre różnice dotyczą obsługi zmiennych środowiskowych i innych takich problemów związanych z bezpieczeństwem. Są to jednak oba narzędzia, które pozwalają zostać innym użytkownikiem, i oba mają domyślnego użytkownika root.

su było oryginalnym narzędziem, wymaga podania hasła użytkownika / grupy, na którą się zmieniasz.

sudojest nowszy i domyślnie wymaga wprowadzenia własnego hasła, ale można go skonfigurować tak, aby akceptował hasło użytkownika / grupy, do którego się przełączasz, lub w ogóle go nie ma. Umożliwia także wiele konfiguracji, z jakimi poleceniami będzie współpracował, dla kogo i jak będzie się uwierzytelniał w tym programie dla tego użytkownika na tym komputerze. Jest to również sudoeditczęść sudoi może być użyte do umożliwienia edycji jako inny użytkownik i uniknięcia problemu bezpieczeństwa wynikającego z podpaskalowania poza edytorem (wywoływanie exec z edytora w celu uruchomienia dowolnego procesu z eskalowanymi uprawnieniami).