Come posso sapere se ho i permessi per eseguire un determinato comando?

Esiste un modo per identificare se io come utente normale ho il diritto di emettere un comando.

Per esempio; Voglio verificare se ho il diritto di emettere il comando shutdown prima di emetterlo effettivamente.

Qualcosa come i seguenti comandi

-> doIhaveRightToIssue shutdown
-> Yes/No

Il caso più semplice è quello di un eseguibile binario come gzip. Innanzitutto, individuiamo l'eseguibile:

$ which gzip
/bin/gzip

Quindi esaminiamo gli attributi di questo file:

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

Le tre x ci dicono che il file può essere eseguito dal proprietario (il primo root), o da chiunque nel gruppo root(secondo root) e da chiunque, rispettivamente. Quindi l'utente può eseguire il programma.

Tuttavia, l'eseguibile potrebbe essere un file di script che chiama altri eseguibili all'interno. Potresti essere in grado di eseguire lo script ma non i programmi chiamati al suo interno. Non c'è modo di determinare se il tuo utente è autorizzato a farlo, se non quello di provarlo.

Quindi ci sono casi speciali come shutdown: questo è davvero un collegamento simbolico a un'utilità principale chiamata systemctl, che ha i suoi meccanismi per determinare se ti è permesso chiamarlo e per chiederti la tua password sudo se non lo fai, per esempio .

(Informazioni sul whichcomando: questo individua gli eseguibili nel tuo $ PATH che ti è permesso eseguire e ti dice quale usi se ne hai più di uno con lo stesso nome nel $ PATH. Non trova alcun eseguibile. I usalo qui come esempio di dove cercare l'autorizzazione. Il fatto che whichtrova l'eseguibile indica già che hai l'autorizzazione per eseguirla.)

Con sudo:

$ sudo -l shutdown
/sbin/shutdown

Se non avessi il permesso, mi sudolamenterò invece di mostrare il comando.

Con polkit, controlli l'azione che desideri eseguire:

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

Trovare l'azione pertinente è una domanda diversa.

Puoi usare:

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

command -v shutdownrestituisce il percorso al shutdowncomando. test -xcontrolla se quel percorso è eseguibile per te.

Si noti che sebbene sia possibile eseguire il comando, il comando potrebbe non riuscire perché non dispone dell'autorizzazione adeguata per eseguire l'attività. Questo è il caso comune sui sistemi di tipo Unix, che invece di limitare l'accesso per eseguire un comando, limitano invece l'accesso alle operazioni che i programmi possono effettivamente fare.

Beh, a volte può essere un po 'difficile ...

Prima di tutto, guarda le autorizzazioni con ls -l...

 comando del gruppo di utenti owngrpotr
-rwxr-xr-x root bin vim

Se l'ultimo / terzo terzetto ha una x ("può eseguire"), allora altri - e questo significa che tu - puoi eseguirlo ... Se si tratta di uno shell-script o qualcosa del genere, allora gli altri avrebbero bisogno di r (" sa leggere anche ").

Se gli altri non hanno il permesso di esecuzione ma il gruppo (la seconda terzina) lo fa, allora puoi eseguirlo se sei un membro del gruppo - nell'esempio sopra, bin . Ad esempio, il gruppo ruota viene spesso utilizzato per limitare chi può essere eseguito su, quindi solo gli utenti appartenenti a questo gruppo possono eseguirlo affatto. Un altro esempio è la creazione di un gruppo per sviluppatori e limitare l'esecuzione del compilatore C e di tali strumenti a questo gruppo.

Se è presente un + finale dopo l'ultima terzina, ciò significa che vengono utilizzati AccessControllLists - questo può aggiungere diritti di esecuzione a utenti e gruppi aggiuntivi.

+++

Anche se sei in grado di eseguire il comando, il comando potrebbe dipendere dall'accesso a file, directory e / o dispositivi a cui non hai accesso - questo potrebbe limitare ciò che sarai in grado di fare (potresti non essere in grado fare qualsiasi cosa).

Alla fine, sebbene ti possa essere permesso di eseguire un comando, il comando stesso può verificare la tua identità e rifiutare di permetterti di usarlo a meno che tu non sia elencato in un file di configurazione o sia un determinato utente (es. Root ). Ad esempio il mountcomando consentirà solo a root di montare qualsiasi dispositivo - gli utenti normali possono montare solo i dispositivi elencati come tali in / etc / fstab ... che potrebbero non essere nessuno. Se non sei root e cerchi di montare qualcosa, mountsi lamenterà e rifiuterà di montare il dispositivo. Un altro esempio è sudoche verrà eseguito per chiunque, ma solo gli utenti elencati in / etc / sudoers potranno effettivamente eseguire le cose come root .

Usando which, type, commandecc è una soluzione pratica che funziona nel 99% dei casi, ma per essere sicuri al 100% si dovrà controllare manualmente ogni directory eseguibile elencato nel vostro $PATH. Molte shell (incluso bash) aggiungeranno il prefisso al comando con entres da $PATHe proveranno ad eseguire ripetutamente quei file fino a quando non avranno successo. Dal momento che whichnon è possibile eseguire il comando, è impossibile prevedere quale file sceglierà la shell.

Ad esempio, immagina di avere PATH=/opt/arm/bin:/binentrambe le directory che contengono file eseguibili, ma per architetture diverse. L'esecuzione which ddtornerà /opt/arm/bin/dd(supponendo che io abbia i permessi per eseguirlo), poiché quella voce viene prima. Tuttavia, quando corro ddnella mia shell, /bin/ddverrà eseguito, perché /opt/arm/bin/ddnon verrà eseguito. La stessa situazione può verificarsi in caso di file binari corrotti, librerie mancanti, ecc. Alla fine, non c'è modo sicuro di sapere se sarai in grado di eseguire un comando o meno, a parte provare.

Un altro aspetto è quello che consideri "avere autorizzazioni". Come utente, ho i permessi per l'esecuzione rm ~/filema non rm /root/file. Ancora una volta, non esiste un modo generale per sapere che senza ispezione manuale, o emettendo il comando e osservando i risultati.