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

S for SWAT Team

Lo so, in fin dei conti c'è un piccolo cavaliere dall'armatura sbrilluccicante dentro di me in cerca di perigliose donzelle da salvare.

E in quale pericolo maggiore le perigliose donzelle possono trovarsi in queste settimane così drammatiche se non avere delle chiavi SSH compromesse per colpa di una patch non approvata in upstream? A proposito: diciamo tutti con forza basta alle patch non approvate upstream. Facciamo uno sciopero se serve¹

Certo, avrei preferito correre in loro soccorso su un bianco destriero (anche se uno gigantesco e nero alla Raoul forse sarebbe meglio) o ancora meglio a bordo di un gigantesco robot nagaiano (ma sono indeciso tra qualcosa alla Mazinga e qualcosa alla Getter Robot) e invece mi tocca accontentarmi di un cavalluccio marino...

Allora perigliose donzelle all'ascolto che non sapete scrivere codice in bash, che non vi va di aprire un Terminale e che non avete una coda di gente davanti alla porta (o dietro, dipende dei punti di vista), ovviamente per prima cosa aggiornate la vostra distribuzione con gli aggiornamenti di sicurezza per ssh/ssl e per seconda cosa, se non c'è già, provvedete a installare il programma seahorse.

Poi facciamo una copia di backup (la sicurezza non è mai troppa quando si parla di sicurezza; per esempio lo sapete che indossare 2 preservativi è più sicuro che indossarne uno solo?) delle vecchie chiavi: apriamo la cartella Home nel file manager, selezioniamo la voce Visualizza → Mostra file nascosti, poi facciamo clic una volta sola sulla cartella .ssh ora visibile e selezioniamo Modifica → Duplica.

A questo punto avviate Seahorse selezionando Applicazioni → Accessori → Password e chiavi di cifratura: vi sia apre una finestrella con attiva la scheda Chiavi personali che elenca le vostre attuali chiavi SSH e GPG. Cancellate la vostra chiave SSH, che è quella con la chiave e lo schermo come icona: fateci clic sopra e poi scegliete Modifica → Cancella chiave.

Ora siete pronte a creare una nuova, fresca, sicura chiave ssh con un semplice Chiave → Crea una nuova chiave. Seguite le istruzioni a schermo, che sono chiare e precise; l'unica cosa è che vi basta fare clic su Crea e non su Crea e configura. Se proprio volete essere pignole aprite l'espansore Opzioni avanzate e controllate che il valore di Tipo di cifratura sia RSA.

Per concludere, quando vi servirà sapere la parte pubblica della vostra neogenerata evangelica chiave, non dovrete fare altro che fare clic sulla chiave in questione e selezionare Chiave → Esporta chiave pubblica, azione che salva un nuovo file di testo il cui contenuto è, per l'appunto, la chiave pubblica.

[1] ah, il controsciopero non è finito, anche se ha raggiunto il suo scopo: semplicemente il controsciopero non è non scrivere stronzate tout-court, ma scrivere cose utili e intelligenti contornate da stronzate a mo' di carte di caramella...