Come fa il SO a sapere che un comando ha bisogno di sudo?


16
  1. Quando esegui un eseguibile, a volte il sistema operativo negherà il tuo permesso. Ad esempio, l'esecuzione make installcon il prefisso è un percorso di sistema sudo, mentre con il prefisso non è richiesto un percorso di sistema sudo. In che modo il sistema operativo decide che l'esecuzione di un eseguibile richiederebbe più privilegi di un utente, anche prima che il programma faccia qualcosa?
  2. A volte, l'esecuzione di un programma non verrà negata l'autorizzazione, ma il programma sarà in grado di fare più cose se viene eseguito con sudo. Ad esempio, quando si esegue dusu una directory di sistema, solo con sudoessa sarà possibile accedere ad alcune directory. Perché il sistema operativo non nega l'autorizzazione a eseguire un programma del genere o si preferisce la notifica amichevole prima di poter eseguire il programma?
  3. È vero che ogni volta che sudofunziona, sufunzionerà anche, e ogni volta che sufunziona, sudofunzionerà anche? o con su, un utente può fare di più che con sudo? Come decide il sistema operativo quando sudofunziona e quando suè necessario?

Ti è stata data una risposta a questa domanda o desideri maggiori informazioni?
ctrl-alt-delor,

Risposte:


14
  1. A volte il messaggio "Autorizzazione negata" è dovuto, ad esempio, alle autorizzazioni del filesystem che ti negano l'accesso in scrittura. L'eseguibile / strumento controlla semplicemente se il filesystem ti concede sufficienti autorizzazioni per fare ciò che stai per fare e genera un errore se negato dal filesystem. Altre volte, lo strumento stesso controllerà il tuo ID utente prima di permetterti di continuare a usarlo.
  2. Quando esegui un programma con sudote lo stai eseguendo con il nome di qualche altro utente. Se quell'utente è "in grado di fare più cose" del tuo utente e la sudoconfigurazione ti consente di fare queste cose per conto dell'altro utente, allora sì, sudoti permetterà di fare più cose. Questo non è necessario, però. Se ti aggiri sudoall'inizio della riga di comando, in realtà stai sudoing root, quindi in genere sei in grado di fare più cose di un semplice mortale.
  3. Assolutamente no. Per utilizzare sudoè necessario fornire la propria password utente e quindi è consentito fare alcune cose per conto dell'utente di destinazione. Per utilizzare su, hai bisogno della password dell'utente di destinazione e, se ce l'hai, diventi quell'utente di destinazione per quanto riguarda il sistema e puoi fare tutto ciò che l'utente può fare.

Guarda anche


Grazie. "Le autorizzazioni del filesystem ti negano l'accesso in scrittura" = "La modalità di accesso al file non ha bit di esecuzione impostato per l'utente, che può essere impostato da chmod"?
StackExchange per tutto il

1
@Tim In realtà it = "la modalità di accesso al file non ha bit di scrittura impostato per l'utente". E sì, questo può ovviamente essere risolto chmodpurché tu sia il proprietario del file o root.
Joseph R.,

Se sudo è necessario, dipende completamente ed esclusivamente dal fatto che il bit di esecuzione non sia impostato per l'utente? Vedi unix.stackexchange.com/q/147052/674
StackExchange per tutto il

@Tim Ovviamente è necessario il bit di esecuzione per poter eseguire l'eseguibile in primo luogo.
Joseph R.,

1
@JosephR. Non ovvio. chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloproduce un bel "Ciao, mondo!" produzione.
doneal24,

24

Per gli scopi descritti, il sistema operativo non decide se è necessario sudo per eseguire inizialmente il programma. Invece, dopo che il programma inizia a funzionare e quindi tenta di fare qualcosa che non è consentito all'utente corrente (come scrivere un file /usr/binper installare un nuovo comando), il sistema operativo impedisce l'accesso al file. L'azione da intraprendere per questa condizione dipende dal programma; makesmette di funzionare ma dupasserà al file / directory successivo dopo aver stampato un messaggio.

I comandi sue sudosono due modi diversi di eseguire un programma con privilegi di root. Possono differire in piccoli dettagli come il contenuto dell'ambiente all'avvio del nuovo programma, a seconda delle opzioni utilizzate. Il sistema operativo non deve decidere quando potrebbe funzionare l'uno o l'altro.


6

sue sudosono programmi privilegiati. sumodifica (dopo l'autenticazione corretta) l'ID utente e gruppo reale ed effettivo a quello dell'utente a cui si è su. Pertanto, suè simile a login. Nota che supuò essere utilizzato per passare a qualsiasi utente, non solo a root. sudocambia anche gli ID utente e gruppo reali ed effettivi. Fino a questo punto sue sudosono simili (ma non correlati), oltre a ciò sono molto diversi.

Con su, è necessario conoscere la password del target e, una volta effettuata l'autenticazione, è possibile fare ciò che si desidera come tale utente. L'uso di supuò essere limitato impostando SU_WHEEL_ONLYin /etc/login.defs. Se impostato, solo gli utenti del gruppo wheelpossono utilizzare su, altrimenti non è limitato. A parte questo, suè tutto o niente.

sudoè completamente diverso rispetto a quello. Con sudote puoi definire politiche piuttosto complesse /etc/sudoerssu ciò che il sudoer (l'utente che chiama sudo) è autorizzato a fare. Ad esempio, è possibile definire criteri in cui determinati utenti possono eseguire solo determinati programmi con determinati privilegi, mentre altri utenti possono eseguire altri programmi con altri privilegi.

Una delle caratteristiche sorprendenti di sudoè che è possibile configurarlo in modo tale che un utente debba autenticarsi con la propria password (anziché quella della destinazione). Pertanto, sudoè diventato molto popolare tra gli amministratori, poiché consente di autorizzare gli utenti a eseguire solo operazioni privilegiate definite senza distribuire la password del superutente, oltre a ottenere un certo grado di responsabilità.


2

tl; dr L'accesso è determinato dall'utente che esegue l'applicazione ed sudoesegue le applicazioni come utente diverso.

Versione completa:

Come fa il SO a sapere che un comando ha bisogno di sudo?

Non lo sa UNIX gestisce le autorizzazioni non a livello di applicazione ma a livello di file system: le autorizzazioni sono concesse agli utenti per accedere a file specifici. Le applicazioni vengono quindi eseguite per conto dell'utente: ogni processo in esecuzione è associato all'utente. Quell'utente viene utilizzato per determinare le autorizzazioni per quell'applicazione. Sudo funziona eseguendo applicazioni per conto di un altro utente (con autorizzazioni associate a quell'altro utente), vale a dire rootil superutente.

Per quanto riguarda i tuoi esempi:

  1. Se l'utente ha accesso in scrittura a una determinata directory, può accedere a make installquella directory. Altrimenti potrebbero averlo rootfatto - usando sudo.

  2. Se non è possibile accedere ai file in una directory, duneanche l'esecuzione in esecuzione per esso. rootpuò accedere praticamente a tutti i file, quindi sudo du( dueseguito per conto di root) può accedervi anche.

È vero che ogni volta che sudo funziona, anche su funzionerà, e ogni volta che su funzionerà, anche sudo funzionerà?

Sì e no. Sì, se il programma è effettivamente eseguito, dovrebbe comportarsi allo stesso modo in entrambi sudoe su. Tuttavia, sudofornisce un controllo più preciso di chi può eseguire cosa per set di regole archiviate nel /etc/sudoersfile. suè più semplice: se conosci la password dell'utente di destinazione, puoi eseguire programmi per conto di tale utente.

Ultima nota: come l'applicazione gestisce la negazione dell'accesso (dove interrompe, ignora o avvisa l'utente) dipende dall'applicazione.


1

Nessuno ha ancora un ✓, quindi ho messo insieme una risposta che ha tutto ciò a cui potevo pensare.

1 Quando si esegue un eseguibile, a volte il sistema operativo negherà l'autorizzazione a. Ad esempio, eseguendo make install con il prefisso che è un percorso di sistema sarà necessario sudo, mentre con il prefisso che è un percorso non di sistema non verrà richiesto sudo. In che modo il sistema operativo decide che l'esecuzione di un eseguibile richiederebbe più privilegi di un utente, anche prima che il programma faccia qualcosa?

No, non viene eseguito all'avvio di un eseguibile. Viene eseguito quando l'eseguibile cerca di fare qualcosa.

L'OS controllerà le autorizzazioni e le capacità del file system (queste non sono coperte dalle autorizzazioni del file system e includono riduzione di buon livello, mknode, alcune cose di rete di basso livello, interruzione dei processi di altri, riavvio, tempo impostato ecc.). Se non si dispone delle autorizzazioni, non è possibile farlo. Il root ha un set completo di funzionalità, incluso CAP_DAC_OVERRIDE (ignora l'autorizzazione del file).

2 A volte, l'esecuzione di un programma non verrà negata l'autorizzazione, ma il programma sarà in grado di fare più cose se viene eseguito con sudo. Ad esempio, quando si esegue du su una directory di sistema, solo con sudo sarà in grado di accedere ad alcune directory. Perché il sistema operativo non nega l'autorizzazione a eseguire un programma del genere o si preferisce la notifica amichevole prima di poter eseguire il programma?

Il sistema operativo non può sapere cosa farà il programma. Quindi spetta al programma controllare i permessi prima che inizi e decidere cosa fare. Non deve farlo però.

Nota: su Android c'è un manifest, in questo l'applicazione dichiara quali privilegi può usare. Il sistema operativo ucciderà qualsiasi applicazione che tenta di utilizzare un privilegio che non dichiara e il sistema operativo non garantisce sempre che un privilegio possa essere onorato. ad es. l'accesso alla rete potrebbe non essere disponibile.

2 È vero che ogni volta che sudo funziona, anche su funzionerà, e ogni volta che su funzionerà anche sudo? o con su, un utente può fare di più che con sudo? Come decide il sistema operativo quando sudo funziona e quando è necessario su?

sudoe sufare all'incirca il samething. Alcune differenze sono la gestione delle variabili di ambiente e altri problemi di sicurezza. Tuttavia, entrambi sono strumenti che ti consentono di diventare un altro utente ed entrambi hanno un utente predefinito root.

su era lo strumento originale, ti richiede di inserire la password dell'utente / gruppo in cui stai cambiando.

sudoè più recente e richiede, per impostazione predefinita, di inserire la propria password, ma può essere configurata per accettare la password dell'utente / gruppo a cui si sta passando o nessuna password. Permette anche molta configurazione, di quali comandi funzionerà, per chi e come si autenticherà con questo programma per questo utente su questa macchina. C'è anche sudoeditquesto è parte di sudoe può essere usato per consentire la modifica come un altro utente ed evitare il problema di sicurezza del sub-shell fuori da un editor (chiamando exec dall'editor per eseguire un processo arbitrario con privilegi di escalation).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.