Not so Short Introduction to PolicyKit 1.0

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 lavoro

Ora 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 complicate

L'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' aggratis

Non 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