Questo mini-HOWTO è una guida a come far andare le applicazioni X in remoto. È stato scritto per parecchie ragioni.
xhost +hostname'' o perfino ``xhost +''
per permettere le connessioni X. Questo è
ridicolmente insicuro, e ci sono metodi migliori. Questo documento è stato scritto avendo in mente sistemi di tipo unix. Se il vostro sistema locale o remoto è di un altro tipo, potrete trovare qua come vanno le cose. Nonostante ciò, dovrete tradurre da soli gli esempi per adattarli al vostro sistema/i.
La versione [inglese] più recente di questo documento è sempre disponibile sul WWW all'indirizzo http://www.xs4all.nl/~zweije/xauth.html. È anche disponibile come il Linux Remote X Apps mini-HOWTO all'indirizzo http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps. I Linux (mini-)HOWTO sono disponibili via http o ftp da sunsite.unc.edu. La traduzione italiana può essere trovata sul sito http://pluto.linux.it e mirror.
Questa è la versione 0.5.1. Non ci sono garanzie,
solo buone intenzioni. Sono disponibile a suggerimenti, idee,
aggiunte, indicazioni utili, correzioni tipografiche, ecc...
Tuttavia vorrei che questo rimanesse un documento semplice
e leggibile, nello stile HOWTO inteso al meglio. I flame
finiscono in /dev/null.
Contenuto aggiornato l'ultima volta il 14 Luglio 1998 da Vincent Zweije. Traduzione italiana a cura di Nicola Pero.
Un documento correlato sul WWW è ``Che cosa fare quando Tk dice che il tuo display è insicuro'' [in inglese], http://ce-toolkit.crd.ge.com/tkxauth/. È stato scritto da Kevin Kenny. Suggerisce una soluzione all'autenticazione X simile a quella suggerita in questo documento (xauth). Tuttavia, Kevin ha più come obiettivo di usare xdm per guidare xauth per voi.
X System Window System Vol. 8, ``Guida dell'Amministratore di X Window System'' [in inglese] da O'Reilly and Associates è stato anche portato alla mia attenzione come una buona fonte di informazione. Sfortunatamente, non ho potuto provarla.
Tuttavia un altro documento molto simile a quello che state leggendo, intitolato ``Rendere X Windows Sicuro'' [in inglese], è disponibile presso http://ciac.llnl.gov/ciac/documents/ciac2316.html.
Potete anche provare usenet newsgroup, come comp.windows.x,
comp.os.linux.x, e comp.os.linux.networking.
State usando due computer. State usando l'X window system del primo per scrivere e guardare. State usando il secondo per fare qualche importante lavoro grafico. Volete far sí che il secondo mostri il suo output sul display del primo. X window system lo rende possibile.
Naturalmente, avete bisogno di una connessione di rete per fare ciò. Preferibilmente una connessione veloce; il protocollo X mangia molte risorse di rete. Ma con un poco di pazienza e un protocollo di compressione adatto, potete eseguire applicazioni perfino attraverso un modem. Per la compressione del protocollo X, potreste voler provare dxpc http://ccwf.cc.utexas.edu/~zvonler/dxpc/ o LBX http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html (anche noto come LBX mini-HOWTO).
Dovete fare due cose per ottenere tutto ciò
La parola magica è DISPLAY.
Nell'X window system, un display consiste (semplificando)
di una tastiera, un mouse e uno schermo. Un display
è gestito da un programma server, conosciuto come server X.
Il server mette a disposizione le capacità di visualizzazione
agli altri programmi che si connettono a lui.
Un display è indicato con un nome, per esempio:
DISPLAY=light.uni.verse:0
DISPLAY=localhost:4
DISPLAY=:0
Il display consiste di uno hostname (come light.uni.verse e
localhost), due punti (:), e un numero di sequenza (come 0
e 4). L'hostname del display è il nome del computer
dove gira il server X. Se l'hostname è omesso si intende
il local host [computer locale]. Il numero di sequenza è
solitamente 0 -- può variare se ci sono più di un display
connessi ad un solo computer.
Se mai vi capita di incontrare una indicazione di display con un .n
in più attaccato, si tratta del numero dello schermo. Un display
può in realtà avere più di uno schermo. Di solito
tuttavia c'è un solo schermo, che ha numero n=0, per cui
questo è il default.
Esistono altre forme di DISPLAY, ma le precedenti sono sufficienti
per i nostri scopi.
Il programma client (per esempio, la vostra applicazione grafica) sa
a quale display deve connettersi da un esame della variabile di
ambiente DISPLAY. Tuttavia questo settaggio può essere
cambiato, dando al client l'argomento di linea di comando
-display hostname:0 quando viene fatto partire. Alcuni esempi
potrebbero rendere le cose più chiare.
Il nostro computer è noto al mondo esterno come light, e
siamo nel dominio uni.verse. Se stiamo facendo andare un server X normale,
il display è conosciuto come light.uni.verse:0. Vogliamo
far partire il programma di disegno xfig su un computer remoto,
chiamato dark.matt.er, e stampare il suo output qua su light.
Supponete di avere già fatto un telnet dentro al computer
remoto, dark.matt.er.
Se avete csh che sta andando sul computer remoto:
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
o alternativamente:
dark% xfig -display light.uni.verse:0 &
Se avete sh che sta andando sul computer remoto:
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
o, alternativamente,
dark$ DISPLAY=light.uni.verse:0 xfig &
o, naturalmente, anche:
dark$ xfig -display light.uni.verse:0 &
Sembra che alcune versioni di telnet trasportino automaticamente
la variabile DISPLAY all'host remoto. Se avete una di queste,
siete fortunati, e non dovete settarlo a mano. Altrimenti,
la maggior parte delle versioni di telnet trasportano la variabile
d'ambiente TERM; con qualche hacking giudizioso è
possibile "piggyback" [lett., portare indietro a maialino]
la variabile DISPLAY sulla variabile TERM.
La idea con il piggybacking è di prepare degli script
per ottenere le cose seguenti: prima di fare il telnet, si attacca
il valore di DISPLAY a TERM. Quindi si fa il telnet.
All'estremità remota, nel file .*shrc appropriato,
si legge il valore di DISPLAY da TERM.
Il server non accetterà connessioni da dovunque come niente fosse. Non volete che tutti possano visualizzare finestre sul vostro schermo. O leggere quello che state scrivendo -- ricordate che la tastiera è parte del vostro display!
Troppa poca gente sembra realizzare che permette di accedere al proprio display pone a rischio la sicurezza. Qualcuno che ha accesso al vostro display può leggere e scrivere sui vostri schermi, leggere che tasti premete, e leggere quello che fa il vostro mouse.
La maggior parte dei server conosce due modi di autenticare le connessioni verso di lui: con la lista di host (xhost) e con i magic cookie (xauth). Infine c'è ssh, la shell sicura, che può trasportare le connessioni X.
Xhost permette l'accesso sulla base degli hostname. Il server mantiene una lista di host che hanno il permesso di connettersi a lui. Può anche disabilitare completamente il controllo degli host. Attenzione: questo significa che non viene fatto nessun controllo, per cui qualunque host può connettersi!
Potete controllare la lista di host del server con il programma xhost. Per usare questo meccanismo nell'esempio precedente, fate:
light$ xhost +dark.matt.er
Questo permette tutte le connessioni dall'host dark.matt.er.
Non appena il vostro client X ha fatto la sua connessione e ha
visualizzato una finestra, per sicurezza, revocate i permessi
di altre connessioni con:
light$ xhost -dark.matt.er
Potete disabilitare il controllo degli host con:
light$ xhost +
Questo disabilita il controllo di accesso degli host e perciò permette a chiunque di connettersi. Non dovete mai fare questo in una rete in cui non vi fidate di tutti gli utenti (come nel caso di Internet). Potete ri-abilitare il controllo degli host con:
light$ xhost -
xhost - da solo non rimuove tutti gli host dalla lista di accesso (il che sarebbe abbastanza inutile - non potreste connettervi da nessun host, nemmeno dal vostro host locale).
Xhost è un meccanismo molto insicuro. Non distingue fra utenti diversi sull'host remoto. Ancora, gli hostname (in realtà gli indirizzi) possono essere spoofati [=falsificati]. Questo è male se vi trovate in una rete di cui non fidarsi (per esempio già con un accesso ad Internet con PPP, via rete telefonica).
Xauth permette l'accesso a chiunque conosca il segreto giusto. Un tale segreto è chiamato codice di autorizzazione, o magic cookie [lett, biscottino magico]. Questo schema di autorizzazione è formalmente chiamato MIT-MAGIC-COOKIE-1.
I cookie per display differenti sono memorizzati insieme nel file
~/.Xauthority. Il vostro ~/.Xauthority
deve essere inaccessibile al gruppo/ad altri utenti. Il programma
xauth amministra questi cookies, da cui il nomignolo xauth per questo schema
di autorizzazione.
Iniziando una sessione, il server legge un cookie dal file che
è indicato dall'argomento -auth. Fatto questo,
il server permette connessioni solo da client che conoscono
questo stesso cookie. Quando il cookie in ~/.Xauthority
cambia, il server non si accorgerà del cambiamento.
Server più recenti possono generare al volo cookies per i client
che lo richiedono. Tuttavia i cookie sono ancora mantenuti dentro il server;
non finiscono in ~/.Xauthority a meno che un client
non li metta là. Secondo David Wiggins:
Un ulteriore espediente che vi potrebbe interessare è stato aggiunto in X11R6.3. Attraverso la nuova estensione SECURITY, il server X stesso può generare e restituire nuovi cookie al volo. Per di più, i cookie possono essere designati come ``untrusted'' [di cui non fidarsi] in modo che applicazioni che fanno connessioni con tali cookie avranno delle restrizioni nelle operazioni. Per esempio, non potranno rubare input di tastiera/mouse, o contenuti di finestre, da altri client di cui ci si fida. C'è ora un sottocomando ``genera'' di xauth per rendere questa funzionalità almeno possibile da usare, se non semplice.
Xauth ha un chiaro vantaggio di sicurezza sopra xhost. Potete limitare l'accesso a utenti specifici su computer specifici. Non soffre per lo spoofing [falsificazione] di indirizzi come fa xhost. E se volete, potete ancora usare xhost insieme a xauth per permettere connessioni.
Se volete usare xauth, dovete far partire il server X con l'argomento
-auth authfile. Se usate lo script startx, è il posto
giusto per farlo. Create una registrazione di autorizzazione, come
mostrato sotto, nel vostro script startx.
Passi scelti da /usr/X11R6/bin/startx:
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Mcookie è un programma minuscolo del pacchetto util-linux,
sito primario
ftp://ftp.math.uio.no/pub/linux/. In alternativa,
potete usare md5sum per rielaborare dei dati casuali
(per esempio, presi da /dev/urandom o ps -axl)
in formato cookie:
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Se non potete editare il file startx (perché non siete root),
fate sistemare per bene startx al vostro amministratore di sistema,
o fategli invece mettere su xdm. Se non può o non vuole,
potete fare uno script ~/.xserverrc.
Se avete questo script, xinit lo esegue al posto del vero server X.
Poi potete far partire il vero server X da questo script con gli
argomenti adeguati. Per fare questo, fate usare al vostro
~/.xserverrc la linea per i magic cookie vista prima
per creare un cookie e quindi eseguire il vero server X:
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Se usate xdm per controllare le vostre sessioni X, potete usare xauth
facilmente. Definite la risorsa .authDir del DisplayManager in
/etc/X11/xdm/xdm-config. Xdm passerà l'argomento
-auth al server X server quando parte. Quando poi voi fate
un log in sotto xdm, xdm mette il cookie
nel vostro ~/.Xauthority per voi.
Si veda xdm(1) per maggiori informazioni. Per esempio,
il mio /etc/X11/xdm/xdm-config
contiene la seguente linea:
DisplayManager.authDir: /var/lib/xdm
Ora che avete incominciato la vostra sessione X sull'host server
light.uni.verse e che avete il vostro cookie in
~/.Xauthority, dovrete trasferire il cookie
all'host client, dark.matt.er.
La cosa più semplice è quando le vostre directory
su light e dark sono condivise. I file ~/.Xauthority
sono gli stessi, per cui il cookie è trasportato simultaneamente.
Tuttavia, c'è un inganno: quando mettete un cookie per
:0 in ~/.Xauthority, dark penserà che sia
un cookie per sé stesso invece che per light. Dovete
usare un host name esplicito quando create un cookie; non potete
tralasciarlo. Potete installare lo stesso cookie sia per
:0 che per light:0 con:
#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Se le home directory non sono condivise, potete trasportare il cookie per mezzo di rsh, la shell remota:
light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -
~/.Xauthority locale
(xauth nlist :0).
| rsh dark.matt.er).
~/.Xauthority là
(xauth nmerge -).
È possibile che rsh non vada bene per voi. A parte questo, rsh ha anche un incoveniente per quanto rigurda la sicurezza (host spoofati [falsificati] di nuovo, se non ricordo male). Se non potete o non volete usare rsh, potete anche trasferire il cookie manualmente, tipo:
light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
dark% xfig &
[15332]
dark% logout
light$
Si vedano anche rsh(1) e xauth(1x) per maggiori informazioni.
Potrebbe essere possibile fare un ``piggyback'' del cookie
nella variabile TERM o DISPLAY quando fate un telnet
all'host remoto. Questo funzionerebbe nello stesso modo in cui
si fa il piggyback della variabile DISPLAY sulla variabile
TERM. Si veda la sezione 5: Dirlo al Client. Dal mio punto
di vista qua sono fatti vostri, ma sono interessato se qualcuno
potesse confermarlo o negarlo.
Una applicazione X su dark.matt.er, come la xfig di prima, guarderà
automaticamente in ~/.Xauthority là per il cookie
con cui autenticarsi.
Le registrazioni di autorità sono trasmesse senza crittografia. Se siete anche solo impensieriti dall'idea che qualcuno possa snoopare [annusare] le vostre connessioni, usate ssh, la shell sicura. Andrà bene per trasportare X sopra connessioni crittate. E inoltre, è grande anche per molti altri motivi. È un buon miglioramento strutturale del vostro sistema. Visitate semplicemente http://www.cs.hut.fi/ssh/, la home page di ssh.
Chi conosce qualcosa d'altra sugli schemi di autenticazione o di crittografia delle connessioni X? Forse kerberos?
La prima volta che cercate di lanciare una applicazione X remota, di solito non funziona. Ecco qua qualche comune messaggio di errore, le sue probabili cause, e soluzioni per aiutarvi.
xterm Xt error: Can't open display:
Non c'è una variabile DISPLAY nell'ambiente, e non avete
neanche parlato all'applicazione con il flag -display. L'applicazione
assume una stringa vuota, ma questa è sintatticamente invalida.
Per risolvere questo problema, assicuratevi di aver settato correttamente
la variabile DISPLAY nell'ambiente (con setenv o export
a seconda della vostra shell).
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
L'Errno 101 è ``Network is unreachable'' [rete irraggiungibile].
L'applicazione non ha potuto fare una connessione
di rete al server. Controllate di avere settato correttamente
DISPLAY, e che la macchina server sia raggiungibile dal vostro
client (lo deve essere, dopotutto siete probabilmente loggati
nel server e state facendo un telnet al client).
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
L'Errno 111 è ``Connection refused'' [Connessione rifiutata]. La macchina server a cui state cercando di connettervi è raggiungibile, ma là il server indicato non esiste. Controllate di stare usando l'host name giusto e il numero di display giusto.
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0
Il client ha potuto fare una connessione al server, ma il server non permette al client di usarlo (non è autorizzato). Assicuratevi di avere trasportato il magic cookie corretto al client, e che non sia espirato (il server usa un nuovo cookie quando incomincia una nuova sessione).