Jak mogę sprawdzić, czy mam uprawnienia do uruchomienia określonego polecenia?

Czy jest jakiś sposób na stwierdzenie, czy ja, jako zwykły użytkownik, mam prawo wydać polecenie.

Na przykład; Chcę sprawdzić, czy mam prawo wydać polecenie zamknięcia przed jej faktycznym wydaniem.

Coś jak następujące polecenia

-> doIhaveRightToIssue shutdown
-> Yes/No

Najprostszym przypadkiem jest binarny plik wykonywalny gzip. Najpierw lokalizujemy plik wykonywalny:

$ which gzip
/bin/gzip

Następnie patrzymy na atrybuty tego pliku:

$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27  2014 /bin/gzip

Trzy x mówią nam, że plik może być wykonany odpowiednio przez właściciela (pierwszego root) lub dowolną osobę w grupie root(drugą root) i kogokolwiek innego. Dzięki temu użytkownik może uruchomić program.

Jednak plik wykonywalny może być plikiem skryptu, który wywołuje inne pliki wykonywalne. Możesz być w stanie wykonać skrypt, ale nie wywoływane w nim programy. Nie ma sposobu, aby ustalić, czy użytkownik może to zrobić, poza próbowaniem tego.

Są też specjalne przypadki, takie jak shutdown- jest to naprawdę symboliczny link do podstawowego narzędzia o nazwie systemctl, które ma własne mechanizmy określające, czy możesz do niego zadzwonić, i poprosić cię o hasło sudo, jeśli nie, na przykład .

(O whichpoleceniu: lokalizuje pliki wykonywalne w $ PATH, które możesz wykonać, i informuje, którego używasz, jeśli masz więcej niż jeden o tej samej nazwie w $ PATH. Nie lokalizuje tylko żadnego pliku wykonywalnego. I użyj go tutaj jako przykładu, gdzie szukać uprawnienia. Fakt, że whichznajduje się plik wykonywalny, już wskazuje, że masz uprawnienia do jego wykonania.)

Z sudo:

$ sudo -l shutdown
/sbin/shutdown

Jeśli nie mam pozwolenia, sudobędę narzekać zamiast pokazywać polecenie.

Dzięki polkit sprawdzasz akcję, którą chcesz uruchomić:

$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkit\56temporary_authorization_id=tmpauthz1
yes

Znalezienie odpowiedniego działania to inna kwestia.

Możesz użyć:

test -x $(command -v shutdown) && echo yes || echo no

command -v shutdownzwraca ścieżkę do shutdownpolecenia. test -xsprawdza, czy ta ścieżka jest dla ciebie wykonywalna.

Zauważ, że chociaż możesz być w stanie wykonać polecenie, polecenie może nadal zawieść, ponieważ ma niewystarczające uprawnienia do wykonania zadania. Jest to częsty przypadek w systemach typu Unix, które zamiast ograniczać dostęp do wykonania polecenia, zamiast tego ograniczają dostęp do operacji, które mogą faktycznie wykonywać programy.

Czasami może to być trochę trudne ...

Przede wszystkim spójrz na uprawnienia z ls -l...

 polecenie grupy użytkowników owngrpotr
-rwxr-xr-x root bin vim

Jeśli ostatnia / trzecia trójka ma w sobie x („może wykonać”), to inni - a to oznacza, że ​​- mogą ją wykonać ... Jeśli jest to skrypt powłoki lub coś w tym rodzaju, inni potrzebowaliby r („ też mogę przeczytać ”).

Jeśli inni nie mają uprawnień do wykonywania, ale grupa je posiada (druga triplet), możesz je wykonać, jeśli jesteś członkiem grupy - w powyższym przykładzie bin . Na przykład grupa kół jest często używana do ograniczania, kto może biegać su, więc tylko użytkownicy należący do tej grupy mogą ją w ogóle wykonać. Innym przykładem jest wykonanie zespołu do opracowania ers i ograniczyć wykonanie kompilator C i takich narzędzi do tej grupy.

Jeśli po ostatniej triplecie występuje znak + , oznacza to, że używane są AccessControllLists - może to dodawać prawa do wykonywania dodatkowych użytkowników i grup.

+++

Nawet jeśli możesz wykonać polecenie, polecenie może zależeć od dostępu do plików, katalogów i / lub urządzeń, do których nie masz dostępu - może to ograniczyć to, co będziesz w stanie zrobić (możesz nie być w stanie robić cokolwiek).

Wreszcie, chociaż możesz zostać upoważniony do wykonania polecenia, samo to polecenie może sprawdzić twoją tożsamość i odmówić ci jej użycia, chyba że jesteś wymieniony w pliku konfiguracyjnym lub nie ma określonych użytkowników (np. Root ). Na przykład mountpolecenie pozwoli tylko rootowi zamontować dowolne urządzenie - zwykli użytkownicy mogą montować tylko urządzenia wymienione jako takie w / etc / fstab ... które mogą być żadne. Jeśli nie jesteś rootem i próbujesz coś zamontować, mountnarzeka i odmówi zamontowania urządzenia. Innym przykładem jest sudo, który będzie działał dla każdego, ale tylko użytkownicy z listy / etc / sudoers będą mogli uruchamiać rzeczy jako root .

Korzystanie which, type, commanditd. Jest to praktyczne rozwiązanie, które będzie działać w 99% przypadków, ale żeby być w 100% pewien, że będziesz musiał ręcznie sprawdzać każdy katalog wykonywalny podanej na stronie $PATH. Wiele powłok (w tym bash) poprzedzi twoją komendę hasłami z $PATHi spróbuje wykonać te pliki wielokrotnie, dopóki się nie powiedzie. Ponieważ whichtak naprawdę nie można wykonać polecenia, nie jest w stanie przewidzieć, który plik naprawdę wybierze twoja powłoka.

Wyobraźmy sobie na przykład, że PATH=/opt/arm/bin:/binoba katalogi zawierają pliki wykonywalne, ale dla różnych architektur. Uruchomienie which ddpowróci /opt/arm/bin/dd(zakładając, że mam uprawnienia do jego wykonania), ponieważ ten wpis jest pierwszy. Jednak gdy uruchomię ddmoją powłokę, /bin/ddzostanie wykonana, ponieważ /opt/arm/bin/ddnie będzie działać. Ta sama sytuacja może się zdarzyć w przypadku uszkodzonych plików binarnych, brakujących bibliotek itp. Ostatecznie nie ma pewności, czy można wykonać polecenie, czy nie, prócz próby.

Kolejnym aspektem jest to, co uważasz za „posiadanie uprawnień”. Jako użytkownik mam uprawnienia do uruchamiania, rm ~/fileale nie mam rm /root/file. Ponownie, nie ma ogólnego sposobu, aby wiedzieć, że bez ręcznej kontroli lub wydania polecenia i obserwacji wyników.