A distanza di
due settimane 7 giorni dall'uscita del miglior Ubuntu di sempre¹, c'è da dire che, al solito, le risorse messe a disposizione da Ubuntu per l'utente mancano di una cosa: una adeguata documentazione di cosa sta per cambiare.
Il passaggio dal vecchio al nuovo (GRUB →
GRUB2, init → upstart) di certo ha portato un po' di miglioramento, ma è ancora assente una chiara documentazione su cosa effettivamente cambia (e perché) e su come mettere mani quando serve.
Visto che mica posso fare tutto io qua dentro, almeno provo a dare il buon esempio. Ecco quindi a voi: "
come fare per incasinare il mio computer concedendo autorizzazioni a destra e manca".
OK, serio. In Ubuntu 9.10 (così come in tutte le altre distribuzioni che usciranno nelle prossime settimane o mesi) diversi programmi utilizzeranno come sistema per l'autenticazione PolicyKit, nella sua rinnovata versione 1.0.
In passato era presente in Sistema → Preferenze (o Sistema → Amministrazione) una applicazione grafica che, funzionale/funzionante o meno, permetteva di definire chi poteva fare cosa e come. Tale applicazione
non c'è più: sinceramente, non sono minimamente d'accordo con quanto dichiarato in quel paragrafo, non mi sognerei mai di rendere mia sorella amministratrice tout-court, anche se mi piacerebbe concederle la possibilità di installare programmi, ma non di rimuoverli.
Rimbocchiamoci le maniche e seguiamo la via del ronin, che conosce il terminale, i file di testo e l'infinita pazienza di leggersi la
documentazione.
Atto primo
in cui l'amministratore si documenta su cosa c'è e cosa non c'èNiente forcerie² grafiche alla Hello Kitty². È un lavoro da uomini veri, duri, puri e un po' pelosetti³. Apriamo un terminale e digitiamo il comando
pkaction | sort
In rigoroso ordine alfabetico, ci vengono elencate tutte le azioni "autenticabili" con PolicyKit, ivi inclusa quella che a noi al momento interessa:
org.debian.apt.install-packages. Si tratta di un'azione gestita dal (nuovo) pacchetto
aptdaemon (una "copia" di PackageKit per deb/apt, utilizzato dal nuovo Ubuntu Software
Store Center). Ovviamente l'esistenza di una azione PolicyKit non vuol dire che tutte le applicazioni ne facciano uso.
Atto secondo
in cui l'amministratore torna dalla necessaria pausa caffè che intercorre ogni 5 minuti di lavoroOra che abbiamo individuato l'azione PK a noi opportuna o necessaria, provvediamo, come abbiamo letto nella
documentazione, a creare un file
.pkla. Tale file dovrà essere collocato nella directory
/var/lib/polkit-1/localauthority/50-local.d, che però è leggibile (e ovviamente modificabile) solo dall'amministratore.
Apriamo quindi il buon editor di testo, tanto caro agli amministatori old-school, e inseriamo al suo interno in testo seguente:
[Users Permissions]
Identity=unix-user:pippo
Action=org.debian.apt.install-packages
ResultAny=no
ResultInactive=no
ResultActive=yes
Ovviamente al posto di "pippo" mettete il nome utente che più vi aggrada (o più nomi utente separati da ; oppure uno o più gruppi con la chiave
unix-group:GRUPPO).
Il significato di ciò che si sta definendo è abbastanza chiaro. Stiamo concedendo un permesso a coloro che corrispondono a un determinata identità di compiere una determinata azione, qualora siano verificati i casi indicati nelle varie chiavi
Result* (sempre, consultare la
documentazione).
Salviamo il file con un nome descrittivo che inizi con un numero (numero che, in caso si vadano a definire più file, determinerà l'ordine di lettura e quindi attuazione delle regole, e quindi i comportamenti). Per esempio
10-pippo-can-install.pkla.
Atto terzo
in cui l'amministratore scalpita per tornare in pausa caffè dopo una lunga serie di azioni noiose e complicateL'ultimo atto da compiere è copiare il file
.pkla appena creato nella posizione opportuna: per questo si apre un bel
Terminale e si esegue il comando:
sudo cp 10-pippo-can-install.pkla /lib/polkit-1/localauthority/50-local.d/
A memoria mi pare di ricordare che non è necessario riavviare il servizio (né tanto meno il computer). La prossima volta che l'utente
pippo tenterà di installare una applicazione con Ubuntu Software Center, il dialogo di autenticazione lo lascerà passare all'inserimento della
sua password, non gli verrà chiesta la password di amministrazione. Ovviamente non potrà installare singoli pacchetti con GDebi, usare Synaptic o aggiornare il sistema... no, in realtà l'aggiornamento può farlo: se non scoprite come, chiedete e vi sarà spiegato
Atto quarto
in cui il vostro opinion leader preferito di turno si lamenta un po' aggratisNon so voi, non so quali siano le vostre esigenze e quanti utenti ci siano sui vostri computer, ma francamente a me le caratteristiche offerte da PolicyKit erano utili, specie nella possibilità di regolazione fine offerta nel decidere chi può fare cosa e come.
La disponibilità di uno strumento grafico era "cosa molto buona", dire che in futuro ci sarà una a "simple group-based UI to a future user account dialog, that will let you declare that a user is an 'Administrator' or a 'Guest'" mi sembra un po' meno. A meno che quel group non sia da intendere come gruppi di azioni.
Sarò io che sto sempre a lamentarmi e mai a fare qualcosa di utile, ma credevo che la regolazione fine fosse necessaria proprio ad evitare di dare a destra e manca permessi di amministrazione.
[1] beh, tra sei mesi mi riservo il diritto di cambiare idea...
[2] oppps... mannaggia al mio sessismo e alla mia omofobia...
[3] anche se mi dicono che esiste la comunità ursina
Se anche tu, come me, usando Linux ricevi ogni spesso archivi ZIP creati in Microsoft Windows versione QuellaCheTiPare e se i documenti ivi archiviati presentano nomi con lettere accentate o in generale non ASCII, ti sarai accorto di come tali documenti non vengano estratti in modo corretto, lamentandosi del fatto che è stata usata una codifica sconosciuta.