22 ottobre 2009

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

7 commenti:

firstbit ha detto...

Ma come gli è venuto in mente di eliminare quel pannello? Io lo trovavo molto comodo...
In ogni caso noto che il vecchio pacchetto policykit-gnome è stato lasciato nei repository universe di karmic. Su Debian le due diverse versioni di policykit convivono (al momento) serenamente (infatti io ho ancora il gestore dei permessi funzionante). Sarà che ancora non è stata completata la migrazione completa a gnome 2.28?

saltydog ha detto...

Cioè???

Da quello che ho capito (anzi, non ho capito) hanno incasinato mezzo mondo.
Non userò mai quella porcheria...

A propo', c'è un typo su "frocerie"! :-)

DnaX ha detto...

Ho inviato un bug riguardo l'impossibilità di ricordare l'autorizzazione al montaggio di dispositivi come si poteva fare con jaunty, mi è stato detto che "la nuova versione di PolicyKit non supporta più tale azione" → Won't fix. Io usavo la GUI a Policy-Kit a adesso ne sono sprovvisto, su alcuni PC avevo dato alcune autorizzazione per launi servizi specifici, adesso mi tocca andare a editare dei fila di sistema, per carità, l'ho sempre fatto, però quella era appunto una ottima funzionalità!

Fe ha detto...

Visto che l'infrastruttura c'è mi pare un po' incredibile quel "non sarà supportato", cioè, mi vogliono dire che polkit-1 manderà a spasso tutta la selezione "fine" dei permessi tornando ai gruppi? Ma... Ma... Se è nato proprio per la selezione fine O.o
Mi perplimo... Comunque anche i tizi che stanno "dietro" a polkit-1 una interfaccetta per 'sta nuova versione la potevano sviluppare.

Anonimo ha detto...

ma porc...e io che bestemmiavo con l'uac di vista appena uscito...quasi quasi torno al 9.04

Glaedr ha detto...

Come, non c'è la possibilità in karmic di memorizzare l'autorizzazione al montaggio?

la nuova versione di PolicyKit non supporta più tale azione

E invece di aggiungere funzionalità le rimuoviamo?!

scimmia ha detto...

Io credo di desiderare la stessa cosa. Vorrei che se clicco su aggiornamenti, quello faccia un update && upgrade senza chiedermi la password, accetto -anzi quasi desidero- me la chieda se per le dipendenze installa qualcosa di nuovo. ho provato come dici tu ma non mi funziona... idee?