Piszę mały program narzędziowy. Chciałbym, żeby spróbował sudo
uruchomić coś, jeśli to konieczne.
To znaczy: jeśli uprawnienia do pliku nie pozwalają bieżącemu użytkownikowi na działanie na określonym pliku (a sudo
reguły na to pozwalają), chciałbym, aby moje narzędzie sudo
uruchomiło coś jako właściciela pliku.
Mam nadzieję sprawdzić tę umiejętność wcześniej, ponieważ wolę, aby dzienniki systemowe nie zapełniały się hałasem spowodowanym nieudanymi sudo
próbami. Jak sudo
sama informuje o awarii: „Ten incydent zostanie zgłoszony”.
Więc mam nadzieję, programowo sprawdzić: można user <x>
uruchomić command <y>
poprzez sudo
?.
Oto problem: chociaż /etc/sudoers
zawiera to mapowanie, jest własnością root i nie jest czytelny dla zwykłych użytkowników.
Zastanawiałem się nad odrodzeniem podprocesu do uruchomienia sudo -l
(który wypisuje polecenia, które bieżący użytkownik może uruchomić sudo). Następnie przeanalizowałbym wynik tego. Wydaje się to jednak trochę kruche. Dane wyjściowe zawierają potrzebne informacje, ale wygląda na to, że zostały zaprojektowane dla ludzi do czytania (nie do konsumpcji programowej). Nie wiem, czy istnieje jakakolwiek gwarancja, że dane wyjściowe będą miały ten sam format w przyszłości lub na różnych platformach.
Czy programowe analizowanie sudo -l
wyników jest uważane za bezpieczne? Jeśli nie, czy są jakieś lepsze opcje, aby ustalić z wyprzedzeniem, czy polecenie sudo się powiedzie?
(tło na X / Y: To narzędzie jest przeznaczone do użytku przez konto roli z ograniczonym dostępem. Oczekuję, że niektórzy inni użytkownicy skutecznie zdecydują się zezwolić, aby konto z ograniczonym dostępem działało na ich plikach za pomocą reguł sudo. Jednak wygrałem nie wiadomo wcześniej, którzy z tych użytkowników mają obowiązującą zasadę sudo)
Odpowiedzi:
Według strony podręcznika sudo:
sprowadzi się to do
Jak podkreślił Muru, użyj jednej
-U $USER
lub-U $USERTOTEST
lub nic, w zależności od potrzeb.źródło
$USER
na myśli bieżącego użytkownika, możesz to zrobićsudo -l <command>
bez-U $USER
.(targetUser) ALL, !/usr/bin/foo
... w takim przypadkusudo -l -u targetUser /usr/bin/foo
nadal wydaje się, że dane wyjściowe/usr/bin/foo
i wyjście ze statusem 0. Nadal jednak wystarczy do mojej prostej kontroli, i analizuje bardziej szczegółowesudo -l
dane wyjściowe.