Czy można sprawdzić zdolność do sudo przed sudo'ingiem?

Piszę mały program narzędziowy. Chciałbym, żeby spróbował sudouruchomić 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 sudoreguły na to pozwalają), chciałbym, aby moje narzędzie sudouruchomił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 sudopróbami. Jak sudosama 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/sudoerszawiera 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 -lwynikó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)

sudo

— Peter Martin
źródło

Polecam ci nieco inne podejście. Zamiast reguł dla poszczególnych użytkowników, dlaczego nie mieć grupy, która może robić wszystko, co chcesz. W ten sposób możesz po prostu sprawdzić, czy użytkownik jest w grupie. Czy byłaby to przyzwoita alternatywa?

— terdon

Według strony podręcznika sudo:

 -l, --list  If no command is specified, list the allowed (and forbidden)
             commands for the invoking user (or the user specified by the
             -U option) on the current host.  A longer list format is used
             if this option is specified multiple times and the security
             policy supports a verbose output format.

             If a command is specified and is permitted by the security
             policy, the fully-qualified path to the command is displayed
             along with any command line arguments.  If command is
             specified but not allowed, sudo will exit with a status value
             of 1.

sprowadzi się to do

if sudo -l -U $USER shutdown > /dev/null
then
   ## $USER can
else
   ## $USER cannot
fi

Jak podkreślił Muru, użyj jednej -U $USERlub -U $USERTOTESTlub nic, w zależności od potrzeb.

— Archemar
źródło

Jeśli masz $USERna myśli bieżącego użytkownika, możesz to zrobić sudo -l <command>bez -U $USER.

— muru

Dzięki - to się przydaje. Jedną z rzeczy, które zauważyłem podczas testowania tego podejścia, jest to, że wydaje się, że nie zajmuje się przypadkami, w których reguła sudo została skonfigurowana tak, aby zezwalać WSZYSTKIM poleceniom z określonymi wyjątkami, takimi jak (targetUser) ALL, !/usr/bin/foo ... w takim przypadku sudo -l -u targetUser /usr/bin/foonadal wydaje się, że dane wyjściowe /usr/bin/fooi wyjście ze statusem 0. Nadal jednak wystarczy do mojej prostej kontroli, i analizuje bardziej szczegółowe sudo -ldane wyjściowe.

— Peter Martin