Privilegi di amministrazione: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
m
(aggiunto pkexec)
(10 versioni intermedie di 2 utenti non mostrate)
Riga 3: Riga 3:
I privilegi di amministrazione (detti anche ''privilegi di root'') permettono di svolgere qualsiasi operazione, dall'alterazione e la cancellazione di qualsiasi file al controllo di tutte le risorse del sistema. E su sistemi operativi Unix e Unix-like, come lo è GNU/Linux Debian, questi privilegi sono assegnati all'utente con [[UID]] pari a '''0''', ossia all'utente [[root]].
I privilegi di amministrazione (detti anche ''privilegi di root'') permettono di svolgere qualsiasi operazione, dall'alterazione e la cancellazione di qualsiasi file al controllo di tutte le risorse del sistema. E su sistemi operativi Unix e Unix-like, come lo è GNU/Linux Debian, questi privilegi sono assegnati all'utente con [[UID]] pari a '''0''', ossia all'utente [[root]].


In tutta questa Wiki, e tradizionalmente per Debian e la maggior parte delle distribuzioni GNU/Linux, si utilizza il carattere di prompt (che non va digitato, ed è già presente nel terminale o nella console virtuale utilizzata) per indicare quali comandi vanno eseguiti con privilegi:
In tutta questa Wiki, e tradizionalmente per Debian e la maggior parte delle distribuzioni GNU/Linux, si utilizza il carattere di prompt (che non va digitato, ed è già presente nel terminale virtuale o nell'emulatore di terminale) per indicare quali comandi vanno eseguiti con privilegi:
* '''<code>$</code>''': il comando che segue è utilizzabile da tutti gli utenti;
* '''<code>$</code>''': il comando che segue è utilizzabile da tutti gli utenti;
* '''<code>#</code>''': sono richiesti i privilegi di root.
* '''<code>#</code>''': sono richiesti i privilegi di root.


Per esempio:
Per esempio:
<pre># apt-get update</pre>
<pre># apt update</pre>
significa che il comando (<code>apt-get update</code>) dev'essere eseguito con privilegi di amministrazione.
significa che il comando (<code>apt update</code>) dev'essere eseguito con privilegi di amministrazione.


== Avvertenze ==
== Avvertenze ==
Riga 47: Riga 47:
''(che identifica sempre l'utente root)''
''(che identifica sempre l'utente root)''


Per essere precisi è stata avviata una nuova [[shell]] di login, e le è stato assegnato il controllo della console virtuale o del terminale (all'interno di una sessione grafica) utilizzato.<br/>
Per essere precisi è stata avviata una nuova [[shell]] di login, e le è stato assegnato il controllo del terminale virtuale o dell'emulatore di terminale (all'interno di una sessione grafica) utilizzato.<br/>
L'opzione <code>-</code> (''trattino'', oppure nelle forme <code>-l</code> e <code>--login</code>) dopo il comando <code>su</code> serve appunto ad avviare una shell di login, che utilizza un ambiente pulito, ereditando soltanto le variabili d'ambiente <code>$TERM</code>, <code>$COLORTERM</code>, <code>$DISPLAY</code> e <code>$XAUTHORITY</code>. Queste ultime due permettono a [[root]] di accedere al server grafico associato all'utente che ha invocato <code>su</code>, se presente e attivo.<br/>
L'opzione <code>-</code> (''trattino'', oppure nelle forme <code>-l</code> e <code>--login</code>) dopo il comando <code>su</code> serve appunto ad avviare una shell di login, che utilizza un ambiente il più possibile pulito.
Alcune variabili d'ambiente però non sono mai ereditate (<code>$HOME</code>, <code>$SHELL</code>, <code>$USER</code>, <code>$LOGNAME</code>, <code>$PATH</code> e <code>$IFS</code>) ed altre (come <code>$LD_PRELOAD</code> e <code>$LD_DEBUG_OUTPUT</code>) non hanno effetto per ragioni di sicurezza.


Si ricordi sempre comunque che può essere '''insicuro''' utilizzare <code>su</code> senza una di queste tre opzioni, equivalenti, che proteggono da possibili errori accidentali causati da un ambiente non pulito: <code>-</code>, <code>-l</code>, <code>--login</code> .
Si ricordi sempre infatti che può essere '''insicuro''' utilizzare <code>su</code> senza una di queste tre opzioni, equivalenti, che proteggono da possibili errori accidentali causati da un ambiente non pulito: <code>-</code>, <code>-l</code>, <code>--login</code> .


Per ritornare utenti normali è necessario terminare la shell, così che il controllo ritorni a quella che si utilizzava precedentemente, con i soli privilegi di utente. Quindi basta digitare il comando:
Per ritornare utenti normali è necessario terminare la shell, così che il controllo ritorni a quella che si utilizzava precedentemente, con i soli privilegi di utente. Quindi basta digitare il comando:
Riga 60: Riga 59:


Nei comandi riportati in tutta questa Wiki, e in generale nella documentazione di tutti i sistemi Unix, il prompt è riportato prima di ogni comando da digitare per indicare se richiede o meno i privilegi di amministrazione.
Nei comandi riportati in tutta questa Wiki, e in generale nella documentazione di tutti i sistemi Unix, il prompt è riportato prima di ogni comando da digitare per indicare se richiede o meno i privilegi di amministrazione.
===== Variabili d'ambiente e programmi grafici =====
Con una nuova shell di login, sono ereditate soltanto le variabili d'ambiente <code>$TERM</code>, <code>$COLORTERM</code>, <code>$DISPLAY</code> e <code>$XAUTHORITY</code>. Queste ultime due permettono a [[root]] di accedere al server grafico (via Xorg) associato all'utente che ha invocato <code>su</code>, se presente e attivo.
Si noti che a partire da Debian 10 ([[Buster]]) soltanto <code>$TERM</code> viene ereditata. Pertanto per lanciare un'applicazione grafica (via Xorg) da terminale come root, è necessario specificare esplicitamente <code>$DISPLAY</code> e <code>$XAUTHORITY</code> ai loro valori precedenti:
<pre>
$ echo $DISPLAY
:0
$ echo $XAUTHORITY
/home/utente/.Xauthority
# su -
# DISPLAY=:0 XAUTHORITY=/home/utente/.Xauthority synaptic
# exit
$
</pre>
È invece rimasto invariato il comportamento di <code>su</code> senza shell di login, per quanto sia sconsigliabile, visto che sarebbero ereditate anche tutte le variabili d'ambiente (si noti infatti che <code>$PATH</code> non è cambiata, e pertanto non conterrà le directory <code>/sbin</code> e <code>/usr/sbin</code>, rendendo necessario specificare il percorso completo di un eseguibile che si trovi in tali directory):
<pre>
$ su -c /usr/sbin/synaptic
$
</pre>
<pre>
$ su
# /usr/sbin/synaptic
# exit
$
</pre>
Alcune variabili d'ambiente non sono mai ereditate in ogni caso (<code>$HOME</code>, <code>$SHELL</code>, <code>$USER</code>, <code>$LOGNAME</code>, <code>$PATH</code> e <code>$IFS</code>) ed altre (come <code>$LD_PRELOAD</code> e <code>$LD_DEBUG_OUTPUT</code>) non hanno effetto per ragioni di sicurezza.
Prima di Debian 10 ([[Buster]]) <code>su</code> modificava la variable <code>$PATH</code> anche quando non era avviata una shell di login, per quanto il suo uso (senza una delle opzioni <code>-</code> / <code>-l</code> / <code>--login</code>) fosse comunque sconsigliato nella maggior parte dei casi.


==== Login diretto come ''root'' ====
==== Login diretto come ''root'' ====
Un'altra possibilità è effettuare direttamente un login come [[root]], solo per lo stretto necessario a svolgere l'attività di amministrazione.
Un'altra possibilità è effettuare direttamente un login come [[root]], solo per lo stretto necessario a svolgere l'attività di amministrazione.


È '''sconsigliato''' effettuare un login da interfaccia grafica, per via dell'elevato numero di applicazioni che riceverebbero i privilegi di amministrazione. Si può invece passare a una console virtuale non utilizzata (per esempio '''/dev/tty2'''), effettuare il login come '''root''', eseguire i soli comandi per cui sono necessari i privilegi di amministrazione e poi effettuare subito dopo il logout, ritornando alla propria console virtuale o comunque a quella utilizzata dal server grafico.
È '''sconsigliato''' effettuare un login da interfaccia grafica, per via dell'elevato numero di applicazioni che riceverebbero i privilegi di amministrazione. Si può invece passare a un terminale virtuale non utilizzato (per esempio '''/dev/tty2'''), effettuare il login come '''root''', eseguire i soli comandi per cui sono necessari i privilegi di amministrazione e poi effettuare subito dopo il logout, ritornando al proprio terminale virtuale o comunque a quello utilizzato dal server grafico.


Per esempio, ecco la procedura per passi (leggerla '''tutta''' prima di provarla!):
Per esempio, ecco la procedura per passi (leggerla '''tutta''' prima di provarla!):
* premere <code>Ctrl-Alt-F2</code> per passare a '''tty2''' (oppure <code>Ctrl-Alt-F3</code> per '''tty3''', ecc... ; basta che la console virtuale sia libera);
* premere <code>Ctrl-Alt-F2</code> per passare a '''tty2''' (oppure <code>Ctrl-Alt-F3</code> per '''tty3''', ecc... ; basta che il terminale virtuale sia libero);
* (in presenza di più persone con accesso al sistema, o se la console '''tty2''' è stata usata in precedenza) inviare la combinazione '''SysRq+K''' premendo <code>Alt-RSist-k</code> (oppure <code>Alt-Stamp-k</code>) per generare una nuova console sicura, terminando tutte le eventuali applicazioni collegate;
* (in presenza di più persone con accesso al sistema, o se la console '''tty2''' è stata usata in precedenza) inviare la combinazione '''SysRq+K''' premendo <code>Alt-RSist-k</code> (oppure <code>Alt-Stamp-k</code>) per generare una nuova console sicura, terminando tutte le eventuali applicazioni collegate;
* effettuare il login con '''root''' e la password corrispondente;  
* effettuare il login con '''root''' e la password corrispondente;  
Riga 76: Riga 106:
Questo metodo, anche se molto più laborioso degli altri, è l'unico sempre '''sicuro''' anche se l'account dell'utente utilizzato per eseguire <code>su</code> o <code>sudo</code> fosse stato compromesso, perché ha il vantaggio di appoggiarsi unicamente sulla sicurezza del sistema.
Questo metodo, anche se molto più laborioso degli altri, è l'unico sempre '''sicuro''' anche se l'account dell'utente utilizzato per eseguire <code>su</code> o <code>sudo</code> fosse stato compromesso, perché ha il vantaggio di appoggiarsi unicamente sulla sicurezza del sistema.


=== Senza account ''root'' ===
=== Utilizzo di ''sudo'' ===
Se durante l'installazione si ha disabilitato l'account '''root''', il primo utente creato è stato automaticamente aggiunto al gruppo '''sudo'''. In tal caso l'unico modo per ottenere '''privilegi di amministrazione''' è tramite [[sudo]].
Se durante l'installazione si ha disabilitato l'account '''root''', il primo utente creato è stato automaticamente aggiunto al gruppo '''sudo'''. In tal caso l'unico modo per ottenere '''privilegi di amministrazione''' è tramite [[sudo]].  
 
In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password e permettere il log dei comandi eseguiti da ciascuna, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password, salvo modifiche della configurazione di default.


==== Utilizzo di ''sudo'' ====
{{Box | Sistemi multiutente | In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password e permettere il log dei comandi eseguiti da ciascuna, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password, salvo modifiche della configurazione di default.}}
'''Sudo''' può essere usato per eseguire un comando come utente [[root]], tramite la richiesta della password dell'utente che esegue il comando, se ha i permessi necessari.


Solitamente, se installato e configurato, si scrive [[sudo]] prima di ogni comando da eseguire con privilegi di amministrazione. <br/>
Solitamente, se installato e configurato, si scrive [[sudo]] prima di ogni comando da eseguire con privilegi di amministrazione. <br/>
Riga 103: Riga 130:
Per maggiori informazioni si rimanda alla guida: [[Configurare SUDO per gestire le attività degli amministratori]]
Per maggiori informazioni si rimanda alla guida: [[Configurare SUDO per gestire le attività degli amministratori]]


=== Con polkit ===
==== Programmi grafici ====
Di default si possono già lanciare applicazioni grafiche con root su un server grafico attivo, ma non come altro utente.
 
=== Utilizzo di ''pkexec'' con polkit ===
Se si è installato uno degli ambienti desktop oppure direttamente il pacchetto '''policykit-1''', che ne è una dipendenza, si può utilizzare il framework di sicurezza ''polkit'' tramite il comando <code>pkexec</code> (azione: ''org.freedesktop.policykit.exec'').
Se si è installato uno degli ambienti desktop oppure direttamente il pacchetto '''policykit-1''', che ne è una dipendenza, si può utilizzare il framework di sicurezza ''polkit'' tramite il comando <code>pkexec</code> (azione: ''org.freedesktop.policykit.exec'').


È installato su Debian con diversi profili di default, per permettere azioni privilegiate a utenti che non dispongono dei privilegi di amministrazione, e permette anche l'esecuzione di comandi che richiedono privilegi di amministrazione. Se è stato attivato l'account [[root]] verrà richiesta la sua password, altrimenti se si è configurato <code>sudo</code> e si fa parte dell'omonimo gruppo verrà richiesta la password dell'utente corrente, in modo trasparente dalle scelte effettuate in fase di installazione.
È installato su Debian con diversi profili di default, per permettere in determinate circostanze azioni privilegiate a utenti che non dispongono dei privilegi di amministrazione, come per esempio: spegnimento, riavvio, sospensione e ibernazione del sistema in assenza di altri utenti collegati.
 
Permette anche l'esecuzione di comandi che richiedono privilegi di amministrazione, previa una forma di autenticazione. Se l'account [[root]] è attivo e non si fa parte del gruppo ''sudo'' verrà richiesta la sua password, altrimenti se si fa parte del gruppo ''sudo'' verrà richiesta la password dell'utente corrente, in modo del tutto trasparente dalle scelte effettuate in fase di installazione.


L'uso è equivalente a <code>sudo</code>, nel senso che il comando va scritto prima di ogni comando che si vuole eseguire con privilegi, e infatti:
L'uso base è molto simile a <code>sudo</code>, nel senso che il comando va scritto prima di ogni comando che si vuole eseguire con privilegi, e infatti:
<pre>
<pre>
$ pkexec id -u
$ pkexec id -u
Riga 114: Riga 146:
restituisce '''0''', ossia l'[[UID]] di [[root]], dopo aver richiesto la password necessaria per ottenere i privilegi.
restituisce '''0''', ossia l'[[UID]] di [[root]], dopo aver richiesto la password necessaria per ottenere i privilegi.


Rispetto a <code>su</code> e <code>sudo</code>, <code>pkexec</code> mostra sempre il comando per cui sono richiesti i privilegi assieme alla richiesta di password, sia in presenza di interfaccia grafica che da console virtuale.
Rispetto a <code>su</code> e <code>sudo</code> però, <code>pkexec</code> mostra sempre il comando per cui sono richiesti i privilegi assieme alla richiesta di password, sia in presenza di interfaccia grafica che da terminale virtuale. Si noti che, salvo personalizzazione dei file di configurazione di ''polkit'', di default è richiesto che l'account root sia attivo oppure che si appartenga al gruppo ''sudo'', altrimenti sarà impossibile essere autenticati.


==== Eseguibili con ''setuid'' ====
==== Programmi grafici ====
{{Warningbox | Questa sezione ha solo scopo didattico, ed è trattata per completezza. Non si dovrebbe '''mai''' ricorrere a tale permesso soltanto per evitare l'autenticazione di un proprio eseguibile, se non si è più che certi di quello che si sta facendo e non è possibile fare altrimenti.
Per alcuni programmi grafici per cui è necessaria l'autenticazione come root sono disponibili dei wrapper che ne permettono l'uso anche da terminale come utente non privilegiato, rimandando l'autenticazione a una finestra grafica. Per esempio per <code>synaptic</code> c<code>synaptic-pkexec</code>:
<pre>
$ synaptic-pkexec
</pre>


Chi si occupa dell'amministrazione non dovrebbe '''mai''' avere la necessità di assegnare ''setuid'' a un programma! È un compito che spetta soltanto a uno sviluppatore, e soltanto in seguito a un'attenta analisi sulle implicazioni sulla sicurezza.}}
Normalmente <code>$DISPLAY</code> e <code>$XAUTHORITY</code> non sono ereditate, ma è possibile specificare diversamente in <code>/usr/share/polkit-1/actions/</code>. Per esempio <code>/usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy</code> contiene:
 
...
Un eseguibile con tale permesso abilitato, anziché ereditare i privilegi dell'utente che lo avvia, è eseguito con quelli del suo proprietario, '''senza nessuna richiesta di autenticazione'''. Ne consegue che un programma appartenente a [[root]] con ''setuid'' è sempre eseguito con '''privilegi di amministrazione''' da chiunque abbia il permesso di esecuzione.
<action id="...">
 
  ...
Per maggiori informazioni si rimanda alla guida: [[Filesystem: i permessi sui files]]
  <annotate key="org.freedesktop.policykit.exec.path">'''/usr/sbin/synaptic'''</annotate>
 
  <annotate key="org.freedesktop.policykit.exec.allow_gui">'''true'''</annotate>
Per ovvie ragioni '''è estremamente pericoloso''' aggiungere tale permesso a eseguibili che ne sono sprovvisti, e rimuoverlo dai comandi di sistema che lo richiedono può ridurre o anche compromettere le funzionalità del sistema.
  ...
 
</action>
Si noti che <code>su</code>, <code>sudo</code> e <code>pkexec</code> per concedere i privilegi di amministrazione fanno uso di questo permesso, senza il quale non potrebbero funzionare per i normali utenti. E sono stati creati proprio per permettere ad altri programmi di essere eseguiti con privilegi, tramite una forma di autenticazione, in modo controllato e sicuro.
...
 
che permetterebbe anche:
Inoltre, per ragioni di sicurezza, il permesso ''setuid'' è ignorato sugli script. E tutte le unità rimovibili, se montate da un utente normale, di default possono esserlo soltanto con il flag '''nosuid''' attivo, che renderebbe il permesso ''setuid'' privo di efficacia.
<pre>
$ pkexec /usr/sbin/synaptic
</pre>


== Esempio: aggiornamento periodico del sistema ==
== Esempio: aggiornamento periodico del sistema ==
Per effettuare l'aggiornamento periodico del sistema su una Debian [[stable]], i comandi da digitare in una console virtuale o un emulatore di terminale con '''privilegi di amministrazione''' sono:
Per effettuare l'aggiornamento periodico del sistema su una Debian [[stable]], i comandi da digitare in un terminale virtuale o in un emulatore di terminale con '''privilegi di amministrazione''' sono:
<pre># apt-get update
<pre># apt update
# apt-get upgrade</pre>
# apt upgrade</pre>
(Si legga per maggiori informazioni: [[Introduzione all' Apt System]])
(Si legga per maggiori informazioni: [[Introduzione all'APT System]])


Nelle sezioni successive è mostrato brevemente come eseguire questi comandi in modo privilegiato con <code>su</code>, <code>sudo</code> e <code>pkexec</code>.
Nelle sezioni successive è mostrato brevemente come eseguire questi comandi in modo privilegiato con <code>su</code>, <code>sudo</code> e <code>pkexec</code>.


{{Box | Login diretto come root | Si noti che effettuando un login diretto come [[root]] su una console virtuale, ovviamente possibile solo con account root attivo, il carattere finale del prompt sarà sempre '''<code>#</code>''' e basterà quindi digitare i due comandi e poi uscire dalla console (premendo <code>Ctrl-d</code>.)}}
{{Box | Login diretto come root | Si noti che effettuando un login diretto come [[root]] su un terminale virtuale, ovviamente possibile solo con account root attivo, il carattere finale del prompt sarà sempre '''<code>#</code>''' e basterà quindi digitare i due comandi e poi uscire dalla console (premendo <code>Ctrl-d</code>.)}}


=== Con account root attivo e su ===
=== Con account root attivo e ''su'' ===
Si avvia una console virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con <code>su</code>:
Si avvia un terminale virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con <code>su</code>:
<pre>$ su -
<pre>$ su -
(richiesta password di root, non stampata a schermo, e INVIO)
(richiesta password di root, non stampata a schermo, e INVIO)
# apt-get update
# apt update
# apt-get upgrade
# apt upgrade
# exit
# exit
$</pre>
$</pre>
Si ricorda nuovamente che il carattere finale del prompt riportato ('''<code>$</code>''' oppure '''<code>#</code>''') non si digita.
Si ricorda nuovamente che il carattere finale del prompt riportato ('''<code>$</code>''' oppure '''<code>#</code>''') non si digita.


=== Senza account root attivo e sudo ===
=== Senza account root attivo e ''sudo'' ===
Se non si è abilitato l'account root, si disporrà del comando <code>sudo</code>, di default attivato per il primo utente creato. Il carattere finale del prompt resterà sempre '''<code>$</code>''', e anziché avviare una shell privilegiata è consigliabile utilizzare <code>sudo</code> prima di ogni comando:
Se non si è abilitato l'account root, si disporrà del comando <code>sudo</code>, di default attivato per il primo utente creato. Il carattere finale del prompt resterà sempre '''<code>$</code>''', e anziché avviare una shell privilegiata è consigliabile utilizzare <code>sudo</code> prima di ogni comando:
<pre>$ sudo apt-get update
<pre>$ sudo apt update
(richiesta password dell'utente, non stampata a schermo, e INVIO)
(richiesta password dell'utente, non stampata a schermo, e INVIO)
$ sudo apt-get upgrade</pre>
$ sudo apt upgrade</pre>
Anche in questo caso il carattere finale del prompt ('''<code>$</code>''') non si digita.
Anche in questo caso il carattere finale del prompt ('''<code>$</code>''') non si digita.


Riga 161: Riga 198:
<pre>$ sudo -k</pre>
<pre>$ sudo -k</pre>


=== Con pkexec ===
=== Con ''pkexec'' ===
Se si è abilitato l'account root, verrà richiesta la sua password, altrimenti verrà richiesta la propria (se si fa parte del gruppo ''sudo''). In entrambi i casi come per <code>sudo</code> il carattere finale del prompt rimarrà sempre '''<code>$</code>''', e si scriverà il comando <code>pkexec</code> prima di ogni comando da eseguire con privilegi:
Come per <code>sudo</code> il carattere finale del prompt rimarrà sempre '''<code>$</code>''', e in maniera analoga si scriverà <code>pkexec</code> prima di ogni comando da eseguire con privilegi:
<pre>$ pkexec apt-get update
<pre>$ pkexec apt update
(richiesta password di root/utente)
(richiesta password di root/utente)
$ pkexec apt-get upgrade
$ pkexec apt upgrade
(richiesta password di root/utente)
(richiesta password di root/utente)
</pre>
</pre>
Riga 171: Riga 208:
Fa parte del framework di autenticazione ''polkit'', presente di default in ogni ambiente desktop.
Fa parte del framework di autenticazione ''polkit'', presente di default in ogni ambiente desktop.


== Approfondimento ==
== Approfondimento: eseguibili ''setuid'' ==
{{Warningbox | Questa sezione ha solo scopo didattico, ed è trattata per completezza. Non si dovrebbe '''mai''' ricorrere a tale permesso soltanto per evitare l'autenticazione di un proprio eseguibile, se non si è più che certi di quello che si sta facendo e non è possibile fare altrimenti.
 
Chi si occupa dell'amministrazione non dovrebbe '''mai''' avere la necessità di assegnare ''setuid'' a un programma! È un compito che spetta soltanto a uno sviluppatore, e soltanto in seguito a un'attenta analisi sulle implicazioni sulla sicurezza.}}
 
Un eseguibile con tale permesso abilitato, anziché ereditare i privilegi dell'utente che lo avvia, è eseguito con quelli del suo proprietario, '''senza nessuna richiesta di autenticazione'''. Ne consegue che un programma appartenente a [[root]] con ''setuid'' è sempre eseguito con '''privilegi di amministrazione''' da chiunque abbia il permesso di esecuzione.
 
Per maggiori informazioni si rimanda alla guida: [[Filesystem: i permessi sui files]]
 
Per ovvie ragioni '''è estremamente pericoloso''' aggiungere tale permesso a eseguibili che ne sono sprovvisti, e rimuoverlo dai comandi di sistema che lo richiedono può ridurre o anche compromettere le funzionalità del sistema.
 
Si noti che <code>su</code>, <code>sudo</code> e <code>pkexec</code> per concedere i privilegi di amministrazione fanno uso di questo permesso, senza il quale non potrebbero funzionare per i normali utenti. E sono stati creati proprio per permettere ad altri programmi di essere eseguiti con privilegi, tramite una forma di autenticazione, in modo controllato e sicuro.
 
Inoltre, per ragioni di sicurezza, il permesso ''setuid'' è ignorato sugli script. E tutte le unità rimovibili, se montate da un utente normale, di default possono esserlo soltanto con il flag '''nosuid''' attivo, che renderebbe il permesso ''setuid'' privo di efficacia.
 
== Approfondimenti ==
<code>man su</code><br/>
<code>man su</code><br/>
<code>man sudo</code><br/>
<code>man sudo</code><br/>
Riga 177: Riga 229:


{{Autori
{{Autori
|Autore= [[Utente:HAL 9000|HAL 9000]] 20:26, 24 apr 2015 (CEST)
|Autore= [[Utente:HAL 9000|HAL 9000]] 14:14, 21 lug 2019 (CEST)
|Verificata_da=
|Verificata_da=
|Numero_revisori=0
|Numero_revisori=0
3 581

contributi

Menu di navigazione