[RISOLTO]Avviare applicazione grafica come altro utente su X

[HAL 9000]

Detta meglio, supponiamo ci siano due utenti, che con grande fantasia chiamerò utente1 e utente2, entrambi diversi da root.

Se utente1 effettua il login in modalità grafica e vuole eseguire un comando come utente2 (chiaramente stando nella home di utente2), gli basta utilizzare sudo, posto che sia tutto configurato a dovere e che il comando funzioni da terminale. Tuttavia se volesse eseguire un programma che richiede l'uso di X, l'utente 2 non riuscirebbe ad autenticarsi presso la sessione attualmente in esecuzione di X.
Il problema non si pone in caso di root, perché può già fare di tutto, ma esiste invece per un utente non privilegiato.

Ho trovato solo un workaround in luogo di sudo:

Codice: Seleziona tutto

utente1$  ssh -X utente2@localhost

che però richiede l'esecuzione del demone ssh, e la sua opportuna configurazione.

Il fatto è che, pur usando il PC da solo, ho creato diversi utenti che uso per compiti specifici, tuttavia occasionalmente ho esigenza di tenere sott'occhio più applicazioni alla volta e continuare a passare da una all'altra non sempre sarebbe il massimo.

Grazie!

[GipPasso]

Se non erro anche root non può collegarsi a una sessione X di un altro utente.

Non è il modo più elegante perché elimina il controllo sull'uid del processo dell'intera sessione X, ma siccome io lo uso molto poco e per periodi limitati è molto comodo:

Codice: Seleziona tutto

xhost +

faccio quello che devo in modo grafico. Finitolo, sempre da untente proprietario della sessione X, do

Codice: Seleziona tutto

xhost -

PS: non ricordo perché mi convinsi che neppure root potesse collegarsi alla mia sessione X. Ho appena provato e, come dice HAL 9000 può.

GipPasso

[HAL 9000]

Ottimo, grazie!

Dal man di xhost vedo che si può restringere l'accesso, anche per singoli utenti con NIS. Tuttavia senza complicarsi troppo la vita, usando local: (che purtroppo non prende argomenti) dovrebbe essere sufficiente, abilitando così l'accesso ai soli utenti locali:

Codice: Seleziona tutto

$ xhost +local:

E per rimettere tutto a posto:

Codice: Seleziona tutto

$ xhost -local:

--- --- --- --- ---
EDIT:

E ancora meglio, se volessi permettere l'accesso soltanto a utente2:

Codice: Seleziona tutto

$ xhost +si:localuser:utente2

E per rimuoverlo, banalmente:

Codice: Seleziona tutto

$ xhost -si:localuser:utente2

--- --- --- --- ---

Per usare programmi che richiedono una sessione X è meglio utilizzare gksudo/kdesudo chiaramente. Solo che questi fallivano se usati con utenti normali.

Ora non dovrò più tenere attivo un demone SSH per niente.

[HAL 9000]

Ripesco una mia vecchia discussione per Xephyr. Permette l'esecuzione di un server X dentro un altro server X, come Xnest, rispetto a cui dovrebbe essere più avanzato.

Per installarlo:

Codice: Seleziona tutto

# apt-get install xserver-xephyr

Il motivo di un server annidato è presto detto: su Xorg c'è un access control attivo soltanto tra display diversi (e di default un utente può connettersi solo al suo display), ma a parte questo non c'è nessuna misura di sicurezza. Se cioè si permette l'accesso a un utente, allora chi può connettersi al display avrà accesso a tutte le risorse del display. E ogni applicazione attiva su un display può (potenzialmente) spiare qualsiasi altra, anche riguardo l'input fornito.
E questo è ancora più indesiderabile in caso di ssh connesso a un host remoto con una redirezione su X.

EDIT: Esiste in realtà un'ulteriore forma di controllo con la suddivisione delle applicazioni connesse al display tra trusted e untrusted, così che quelle untrusted non possano immettere né osservare l'input di quelle trusted. È questa la configurazione standard quando si usa ssh e si redirige l'input con l'opzione -X (se si utilizza -Y si utilizza invece la "trusted", il che significa che l'applicazione avrà accesso a tutte le risorse del display). Usando -X l'uso di Xephyr potrebbe essere ridondante, ma potrebbe essere usato per avviare un'intera sessione grafica e ridirigerla su Xephyr.

--- --- --- --- ---

Comunque senza tirare in ballo ssh, per ora, se si vuole confinare un'applicazione locale a essere eseguita con i permessi di un altro utente, sudo lo permette una volta configurato sudoers (via visudo). Ma in caso di applicazioni grafiche resta il problema dell'inaffidabilità di Xorg.
Con Xephyr invece, dall'interno della sessione dell'utente1 (supponendo che sia su display :0, ma basta controllare $DISPLAY), apriamo un nuovo display (che io considero :1 da qui in avanti) che sarà contenuto in una finestra della sessione corrente:

Codice: Seleziona tutto

$ Xephyr -ac -reset -terminate -nolisten tcp -screen XRESxYRES :1 &

(-ac disabilita l'access control su Xephyr, -reset e -terminate assicurano la chiusura quando esce l'ultimo client connesso, -nolisten tcp per disabilitare l'ascolto su TCP (IPv4 e IPv6) visto che si usa localmente, -screen imposta la risoluzione da usare per Xephyr, :1 è l'ID del nuovo display/finestra da usare e dev'essere libero).

Dopodiché è possibile eseguire applicazioni come un altro utente con sudo, collegandolo al display appena aperto:

Codice: Seleziona tutto

$ DISPLAY=:1 sudo -u utente2 -- applicazione-non-così-fidata

L'applicazione-non-così-fidata non potrà leggere né inviare tasti al di fuori di Xephyr, e avrà i permessi per leggere e scrivere nella sola home dell'utente2.

È da notare che l'opposto non vale, ovvero l'applicazione può essere (potenzialmente) "spiata" da tutte le applicazioni dell'utente1 (e non solo, visto l'access control di Xephyr disabilitato). Quindi per eseguire al sicuro una singola applicazione grafica, l'unica è utilizzare un account dedicato su display dedicato.

--- --- --- --- ---

Per non disattivare l'access control nemmeno in Xephyr, si può utilizzare xauth per creare un nuovo file Xauthority, lasciandone la lettura al solo gruppo dell'utente2. Di seguito presento l'alternativa, tutto dev'essere eseguito sempre dall'utente1.

Creo un file vuoto con nome desiderato, ma in un percorso leggibile da entrambi utente1 e utente2, da usare come Xauthority per il nuovo display:

Codice: Seleziona tutto

$ touch /tmp/.xauth-xephyr.1

Aggiungo l'autorizzazione, usando il protocollo basato sul "magic cookie" (il "punto" è un alias), che viene generato da mcookie e passato (in chiaro...) a xauth per aggiungerlo al nuovo Xauthority:

Codice: Seleziona tutto

$ xauth -f /tmp/.xauth-xephyr.1 add "$(hostname)/unix:1" . "$(mcookie)"

Modifico i permessi del file, permettendone la lettura al gruppo (di default xauth dovrebbe toglierla), e cambio il gruppo in quello dell'utente2:

Codice: Seleziona tutto

$ chmod 640 /tmp/.xauth-xephyr.1
$ chgrp utente2 /tmp/.xauth-xephyr.1 # utente1 deve appartenere al gruppo di utente2 o servono i privilegi di admin

Avvio Xephyr con gli stessi parametri di prima, a parte che non c'è -ac (perché l'access control resta attivo anche lì) e utilizzo il file authority con -auth:

Codice: Seleziona tutto

$ Xephyr :1 -reset -terminate -nolisten tcp -screen XRESxYRES -auth /tmp/.xauth-xephyr.1 &

Lancio sempre come utente1, collegandomi al display e autenticandomi con il file Xauthority indicati, l'applicazione con sudo:

Codice: Seleziona tutto

$ DISPLAY=:1 XAUTHORITY=/tmp/.xauth-xephyr.1 sudo -u utente2 -- applicazione-non-così-fidata

Per avere maggiore controllo è possibile avviare anche un window manager, al posto dell'applicazione, con pannello e menù già integrati, come blackbox. E poi avviare le applicazioni dentro Xephyr da lì in modo grafico.


L'unico problema rimasto è l'esecuzione di applicazioni Qt.