Co decyduje o tym, które polecenia systemu Linux wymagają dostępu do konta root?

Co decyduje o tym, które polecenia systemu Linux wymagają dostępu do konta root? Rozumiem powody, dla których pożądane jest, powiedzmy, apt-getwymaganie rootprzywilejów; ale co odróżnia te polecenia od reszty? Czy to po prostu kwestia własności i wykonywania uprawnień do pliku wykonywalnego?

W Linuksie, przywileje korzenia były w jednym punkcie podzielone na „możliwości”, dzięki czemu można uzyskać pełną listę specjalnymi uprawnieniami roota, patrząc na tej dokumentacji: man 7 capabilities.

Aby odpowiedzieć na twoje pytanie, polecenie będzie wymagało uruchomienia jako root, gdy potrzebuje jednego z tych uprawnień, a jego plik wykonywalny nieskryptowy nie ma ustawionej odpowiedniej zdolności w swoich metadanych pliku (np. Jeśli skrypt python wymaga takiej możliwości, wtedy zdolność musiałby być w interpreterze python określonym w linii shebang).

Zauważ, że niektóre polecenia, które wymagają dostępu do roota, nie potrzebują czegoś takiego, sudoponieważ mają ustawiony bit SUID w swoim pliku wykonywalnym. Ten bit powoduje, że plik wykonywalny działa jako właściciel (zwykle root), gdy jest wykonywany przez każdego, kto ma dostęp do wykonywania. Przykład sudosam w sobie, ponieważ zmiana użytkowników jest uprzywilejowaną akcją, którą musi wykonać.

EDYCJA: Z twojego pytania wynika, że ​​możesz mieć pomysł, aby ustalić, czy polecenie będzie wymagało dostępu do konta root przed jego uruchomieniem. To nie o to chodzi. Program może czasami wymagać uprawnień roota, a innym razem nie, a może to być decyzja podjęta przez program z powodu danych dostarczonych podczas działania. Weźmy na przykład wywoływanie vim, podobnie jak bez argumentów, a następnie szereg naciśnięć klawiszy i wklejanie, mówiąc mu, aby napisał coś do pliku, do którego nie ma uprawnień do zapisu, lub może wykonać inną komendę, która sama będzie wymagać uprawnień administratora. Nic o komendzie przed wykonaniem nie może wskazywać, że ostatecznie wymagałoby to dostępu do konta root. Jest to coś, co można ustalić tylko w momencie, gdy próbuje zrobić coś, co tego wymaga.

W każdym razie oto kilka przykładów z przywoływanej strony przywilejów roota:

• Wykonuj dowolne manipulacje procesowymi identyfikatorami UID (setuid (2), setreuid (2), setresuid (2), setfsuid (2));
• Pominięcie odczytu, zapisu i wykonywania pliku z uprawnieniami. (DAC to skrót od „uznaniowej kontroli dostępu”).
• Pomiń sprawdzanie uprawnień do wysyłania sygnałów (patrz kill (2)). Obejmuje to użycie operacji KDSIGACCEPT ioctl (2).
• Wykonuj różne operacje związane z siecią:
  • konfiguracja interfejsu;
  • administracja zaporą IP, maskarada i księgowość;
  • modyfikuj tabele routingu;
• Powiąż gniazdo z portami uprzywilejowanymi w domenie internetowej (numery portów mniejsze niż 1024).
• Ładowanie i rozładowywanie modułów jądra (patrz init_module (2) i delete_module (2));
• Ustaw zegar systemowy (settimeofday (2), stime (2), adjtimex (2)); ustaw zegar czasu rzeczywistego (sprzętowy).
• Wykonaj szereg operacji administracyjnych systemu, w tym: quotactl (2), mount (2), umount (2), swapon (2), swapoff (2), sethostname (2) i setdomainname (2);
• Użyj restartu (2) i kexec_load (2).
• Użyj chroot (2).
• Podnieś wartość Nice procesu (nice (2), setpriority (2)) i zmień wartość Nicei dla dowolnych procesów;

Jest to głównie kwestia tego, co narzędzie lub program robi . Pamiętając, że osoba niebędąca superużytkownikiem może dotykać tylko plików, do których jest właścicielem lub do których ma dostęp, każde narzędzie, które musi mieć dostęp do wszystkiego, będzie wymagało dostępu administratora w celu wykonania tego, co robi. Szybka próbka rzeczy, które mogą wymagać dostępu administratora, obejmuje między innymi:

• Otwieranie nasłuchującego gniazda TCP na porcie poniżej 1024
• Zmienianie konfiguracji systemu (np. Cokolwiek w /etc)
• Dodawanie nowych globalnie dostępnych bibliotek ( /libi /usr/lib) lub plików binarnych ( /bin, /usr/bin)
• Dotykanie plików, które nie są własnością użytkownika wykonującego dotykanie, które nie mają dostatecznie dopuszczalnego trybu
• Zmiana własności plików innych użytkowników
• Realizowanie priorytetów procesu (np. renice)
• Uruchamianie lub zatrzymywanie większości usług
• Konfiguracja jądra (np. Dostosowanie swapiness)
• Dostosowanie limitów systemu plików
• Zapis na „pełnych” dyskach (większość systemów plików rezerwuje miejsce dla użytkownika root)
• Wykonywanie czynności jak inni użytkownicy

Myślę, że weryfikacja uprawnień jest zgodna z tożsamością użytkownika, a nie zgodnie z kolejnością podziału uprawnień. Pliki i użytkownicy są uprzywilejowani, a poleceń nie należy dzielić.