{"id":457,"date":"2014-11-03T17:02:46","date_gmt":"2014-11-03T16:02:46","guid":{"rendered":"http:\/\/gabrielezappi.net\/?p=457"},"modified":"2014-11-04T10:55:51","modified_gmt":"2014-11-04T09:55:51","slug":"come-abilitare-sudo-con-lo-stesso-comportamento-di-ubuntu-desktop-ad-altre-distribuzioni-linux","status":"publish","type":"post","link":"https:\/\/gabrielezappi.net\/en\/come-abilitare-sudo-con-lo-stesso-comportamento-di-ubuntu-desktop-ad-altre-distribuzioni-linux\/","title":{"rendered":"Come abilitare sudo con lo stesso comportamento di Ubuntu Desktop, ad altre distribuzioni Linux."},"content":{"rendered":"

\"SupermanULogo\"<\/a><\/p>\n

Ubuntu linux, come molti sapranno, \u00e8 stato “ritoccato<\/em>” in modo tale che tutte le volte che viene richiesta una password amministrativa (come utente “root”), l’utente normale, ossia non privilegiato, tramite comando ‘sudo<\/strong><\/em>‘ pu\u00f2, inserendo la sua password personale, acquisire temporaneamente i privilegi di root per eseguire tale comando (sempre che sia stato abilitato a farlo!). Non solo: anche tutte le finestre di dialogo grafiche (sia dell’ambiente gnome e affini, che di Kde) che richiedono l’introduzione di una password per verificare i diritti di root a fronte di un’operazione di sistema (es. aggiunta di un utente, installazione di un aggiornamento, ecc.), si comporteranno alla stessa maniera, ovvero chiederanno la password dell’utente<\/strong><\/span>, e non quella di root<\/span><\/strong>.<\/p>\n

Tant’\u00e8 che nei sistemi ubuntu desktop, durante l’installazione standard, di default la password di root non viene nemmeno richiesta, in quanto verr\u00e0 creato un utente iniziale che avr\u00e0 gi\u00e0 l’autorizzazione ad eseguire comandi amministrativi prefissandoli con il comando sudo<\/strong>.<\/span><\/address>\n

Per applicare lo stesso funzionamento ad altre distribuzioni (ad esempio Debian), seguire i seguenti passi:<\/p>\n

    \n
  1. aptitude install sudo<\/strong><\/li>\n
  2. su root<\/strong> (al momento..)<\/li>\n
  3. visudo<\/strong>
    \nInserire una riga nel file che assomiglia alla seguente:<\/p>\n
    nome_utente\u00a0ALL=(ALL:ALL) ALL<\/pre>\n
    sostituendo ovviamente ‘nome_utente<\/em>‘ al login name del vostro utente.
    \nUscire salvando il file.<\/li>\n
  4. Al prossimo accesso, l’utente ‘nome_utente<\/em>‘ avr\u00e0 la possibilit\u00e0, ad esempio, di eseguire il comando:
    \nsudo ls -la \/root<\/strong>
    \nDopo aver introdotto la sua password personale, se tutto \u00e8 andato bene, gli verr\u00e0 visualizzato il contenuto della cartella home dell’utente root. (In caso contrario, uscirebbe un errore, in quanto solo root, di norma, pu\u00f2 vedere quella cartella)<\/li>\n<\/ol>\n
    Tuttavia, alla procedura descritta sopra, a mio avviso \u00e8 preferibile un “ritocco”. \u00a0Per due motivi. \u00a0Il primo: avendo pi\u00f9 utenti di sistema e qualora debbano eseguire comandi di root, sarei costretto per ciascuno di loro, inserire una riga nel file \/etc\/sudoers<\/strong> (o tramite comando ‘visudo<\/strong>‘), la linea che lo abilita. Secondo: In genere Debian (ma anche altre distro) ha gi\u00e0 un gruppo definito appunto “sudo<\/span><\/strong>“, che \u00e8 gi\u00e0 presente a sistema, ed \u00e8 gi\u00e0 presente nella configurazione di \/etc\/sudoers<\/strong> a concedere i permessi\u00a0amministrativi in caso di esecuzione di comando ‘sudo<\/strong>‘ a tutti i membri del gruppo stesso<\/span>. Infatti se si guarda nel file visualizzato da ‘visudo<\/strong>‘, dovrebbe gi\u00e0 esistere una riga simile alla seguente (se non dovesse esistere, aggiungerla):<\/p>\n
    %sudo ALL=(ALL:ALL) ALL<\/pre>\n
    (Nota<\/span>: il carattere ‘%’ prima del nome, significa che la direttiva si riferisce ad un gruppo, e non ad un utente).<\/p>\n
    A questo punto, \u00e8 sufficiente inserire l’utente come membro del gruppo “sudo<\/strong>” con il seguente comando:<\/p>\n
    adduser nome_utente sudo<\/pre>\n
    A quel punto, l’utente ‘nome_utente<\/strong>‘, potr\u00e0 eseguire comandi come utente root prefissandoli con “sudo”.<\/p>\n
    Es.<\/p>\n
    sudo apt-get update<\/strong><\/em><\/p>\n
    \n
    Nota: la prima volta che l’utente usa il comando “sudo”, ricever\u00e0 questo output:<\/span><\/p>\n
    We trust you have received the usual lecture from the local System\u00a0Administrator. It usually boils down to these three things:<\/span>\r\n#1) Respect the privacy of others.\r\n#2) Think before you type.\r\n#3) With great power comes great responsibility.\r\n[sudo] password for nome_utente:<\/em><\/pre>\n

    \nO il corrispondente messaggio\u00a0in italiano. <\/span><\/p>\n
    Questa lezione dovrebbe essere stata impartita dall'amministratore di sistema locale. Solitamente equivale a:<\/span>\r\n#1) Rispettare la privacy degli altri\r\n#2) Pensare prima di digitare\r\n#3) Da grandi poteri derivano grandi responsabilit\u00e0\r\n[sudo] password for nome_utente:<\/em><\/pre>\n
    Dal successivo utilizzo del comando, questo messaggio non verr\u00e0 pi\u00f9 visualizzato.<\/span><\/p>\n
    \n
    Comandi grafici di richiesta autorizzazioni amministrative, in ambiente Gnome e KDE.<\/h2>\n
    Quanto detto sopra, imposta il sistema come desiderato utilizzando il comando sudo da linea di comando (CLI<\/em>). In molte circostanze, invece, quanto un’applicazione grafica ci richiede i permessi di root tramite una dialog box via GUI<\/em>, o in ambiente Gnome<\/span><\/strong> o Kde<\/strong><\/span>, il comportamento spesso \u00e8 ancora quello di richiederci la password di root, e NON<\/span> la nostra da normale utente.<\/p>\n
    C’\u00e8 stata un po’ di confusione, nel tempo, nei vari front-end grafici come kdesu<\/strong> e kdesudo<\/strong> per KDE<\/strong> o gksu<\/strong> e gksudo<\/strong> per l’ambiente Gnome<\/strong> e affini.<\/p>\n
    Riguardo a KDE, ultimamente dovrebbero essere stati sistemati i problemi in quanto kdesu<\/strong> nella maggior parte dei casi, altro non \u00e8 che un link simbolico a kdesudo<\/strong><\/span>. In altre parole, di default i front-end di KDE, all’occorrenza dovrebbe chiedere in ogni caso la password dell’utente e non quella di root. (Se cos\u00ec non fosse, controllare nel percorso di kdesu se \u00e8 un link simbolico di kdesudo<\/span>. Se cosi non fosse, rimuovere o rinominare kdesu e lanciare, da root, il seguente comando<\/span>: ln -s \/usr\/bin\/kdesudo \/usr\/bin\/kdesu<\/strong>).<\/p>\n
    Diverso \u00e8 invece il discorso per i front-end di Gnome: nelle ultime versioni viene rilasciato solo gksu<\/strong> e non gksudo<\/strong><\/span>, e gksudo<\/strong> \u00e8 un link simbolico verso gksu<\/strong><\/span> (praticamente il contrario di quanto avviene in KDE!!). Quindi per dirgli di comportarsi come sudo (e non come su), occorre andare nei registri di Gnome<\/span> tramite il comando ‘gconftool<\/strong>‘ (o se si preferisce, tramite front-end grafico ‘gconf-editor’<\/em>), ed impartire il seguente comando:<\/p>\n
    gconftool -s \/apps\/gksu\/sudo-mode --type=bool true<\/strong><\/pre>\n
    (o, se si adopera gconf-editor<\/strong>, scorrere nella stessa voce dell’albero apps->gksu<\/strong>, ed impostare il valore del registro sudo-mode<\/strong> a 1<\/strong>)<\/p>\n
    Da questo punto in avanti, anche il front-end grafico di Gnome chieder\u00e0 la password dell’utente (e non<\/span> pi\u00f9 quella di root), quando richiesto, per svolgere\u00a0compiti amministrativi.<\/p>\n
    Mi auguro che questo articolo possa essere di aiuto a qualcuno.<\/p>\n
    Cordialmente,
    \nGabriele<\/em><\/strong><\/p>\n
     <\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    Ubuntu linux, come molti sapranno, \u00e8 stato “ritoccato” in modo tale che tutte le volte che viene richiesta una password amministrativa (come utente “root”), l’utente normale, ossia non privilegiato, tramite comando ‘sudo‘ pu\u00f2, inserendo la sua password personale, acquisire temporaneamente i privilegi di root per eseguire tale comando (sempre che sia stato abilitato a farlo!). … Continue reading Come abilitare sudo con lo stesso comportamento di Ubuntu Desktop, ad altre distribuzioni Linux.<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-457","post","type-post","status-publish","format-standard","hentry","category-senza-categoria"],"_links":{"self":[{"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/posts\/457","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/comments?post=457"}],"version-history":[{"count":8,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/posts\/457\/revisions"}],"predecessor-version":[{"id":469,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/posts\/457\/revisions\/469"}],"wp:attachment":[{"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/media?parent=457"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/categories?post=457"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gabrielezappi.net\/en\/wp-json\/wp\/v2\/tags?post=457"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}