test

Guida avanzata a Solaris

Appendice D Uso delle applicazioni in rete

Uso delle applicazioni in rete

Questa appendice descrive una funzione avanzata dell'ambiente OpenWindows che consente di eseguire applicazioni residenti in un'altra workstation della rete.

Nota -

Le informazioni contenute in questa appendice non sono strettamente necessarie per l'uso di OpenWindows. Per avere maggiori informazioni sulle caratteristiche delle applicazioni in rete e sulle risorse disponibili, rivolgersi all'amministratore del sistema.

In generale, nell'ambiente OpenWindows le applicazioni che compaiono sullo schermo (come Posta Elettronica e Calendario) sono programmi eseguiti sulla workstation locale. Se tuttavia la workstation fa parte di una rete, è possibile eseguire le applicazioni da un altro sistema e visualizzarle sul sistema locale. Questo permette di ridurre i cicli di calcolo sul sistema locale e di accedere a tutte le applicazioni disponibili nella rete.

Questa appendice descrive le procedure più semplici da seguire per eseguire un'applicazione su un sistema remoto e visualizzarla sul proprio schermo. Poiché l'ambiente operativo può variare da un sistema all'altro, si consiglia di seguire queste istruzioni con una certa flessibilità. Per informazioni sulle modalità d'uso più complesse delle applicazioni in rete, vedere il paragrafo "Sicurezza della rete".

Per eseguire un'applicazione remota nel modo descritto sono necessari i seguenti requisiti:

Per informazioni più precise sulle condizioni richieste, rivolgersi all'amministratore del sistema.

Uso di rlogin per eseguire un'applicazione in rete

Per eseguire un'applicazione in rete da un sistema remoto è essenziale che le variabili d'ambiente siano impostate correttamente:

L'esempio seguente spiega come avviare una Finestra di comando da un sistema remoto usando rlogin. In questo esempio, la directory home dell'utente è attivata sul sistema remoto in /home/directory_utente, mentre il software di OpenWindows si trova in /usr/openwin sul sistema remoto. Le variabili directoryutente e sistemautente devono essere impostate nel modo appropriato per la propria configurazione. Inoltre, cmdtool deve essere sostituito con il nome dell'applicazione che si desidera eseguire. 

$ rlogin sistemaremoto
   .
   .
(I comandi seguenti vengono eseguiti sul sistema remoto.)
   .
   .
$ HOME=/home/directoryutente
$ DISPLAY=sistemautente:0
$ LD_LIBRARY_PATH=/usr/openwin/lib
$ /usr/openwin/bin/cmdtool &

Dopo aver inserito l'ultima riga, sul proprio schermo compare una Finestra di comando. Questa finestra può essere utilizzata in modo interattivo come qualsiasi altra applicazione aperta nell'area di lavoro, ma viene eseguita in realtà sul sistema remoto.

L'uso di una Finestra di comando in questo modo non presenta particolari vantaggi (l'applicazione è già disponibile sul sistema locale e non richiede una grande quantità di memoria); la procedura descritta può essere comunque utilizzata per qualsiasi applicazione remota.

Sicurezza della rete

Questo paragrafo descrive alcuni principi fondamentali riguardanti la sicurezza della rete, tra cui:

Condizioni per la modifica del sistema di sicurezza

La configurazione di sicurezza di default di OpenWindows 3.3 e delle versioni successive deve essere modificata solo nei seguenti casi:

Meccanismi di controllo degli accessi

I meccanismi di controllo degli accessi permettono di stabilire quali client o applicazioni possono avere accesso al server X11. Solo i client provvisti delle autorizzazioni corrette possono accedere al server; a tutti gli altri l'accesso viene negato, e il processo viene terminato con il seguente messaggio di errore. 

Xlib: connection to nomehost refused by server
Xlib: Client is not authorized to connect to server

Il tentativo di connessione viene registrato nel log della console del server come segue:

AUDIT: <Data Ora Anno>: X: client 6 rejected from IP 129.144.152.193
port 3485
	Auth name: MIT-MAGIC-COOKIE-1

I meccanismi di controllo degli accessi si dividono in due tipi: riferiti all'utente e riferiti all'host. Nel primo caso l'accesso al server viene concesso a uno specifico profilo utente, nel secondo caso a un determinato host o sistema. Di norma sono attivi entrambi i meccanismi di controllo, salvo i casi in cui il comando openwin viene eseguito con l'opzione -noauth. Per maggiori informazioni, vedere "Gestione degli accessi al server" in questo capitolo.

Accesso riferito all'utente

Con i meccanismi riferiti all'utente, l'accesso al server viene concesso a un determinato utente indipendentemente dall'host utilizzato. Il client dell'utente comunica i dati di autorizzazione al server, e se questi corrispondono a quelli impostati sul server, l'utente ottiene il diritto di accesso.

Accesso riferito all'host

I meccanismi riferiti all'host operano con criteri più generali. In questo caso l'accesso al server viene concesso a un determinato host, e di conseguenza a tutti gli utenti che operano su tale host. Si tratta di una forma di controllo più debole: se l'host ha accesso al server, l'autorizzazione viene estesa automaticamente a tutti gli utenti che lo utilizzano.

I meccanismi di controllo riferiti all'host vengono usati generalmente per garantire la compatibilità all'indietro. Le applicazioni collegate con versioni di Xlib o libcps anteriori a OpenWindows versione 2 o a X11R4 non riconoscono i nuovi meccanismi di controllo riferiti all'utente. Per ottenere l'accesso al server con queste applicazioni, perciò, l'utente deve attivare il meccanismo riferito all'host oppure rieffettuare il collegamento con una versione più recente di Xlib e libcps.

Nota -

Se possibile, i client collegati con una vecchia versione di Xlib o libcps dovrebbero essere ricollegati con versioni più aggiornate delle librerie, in modo da consentire la loro connessione al server con il nuovo meccanismo di controllo riferito all'utente.

Protocolli di autorizzazione

Questa versione di OpenWindows supporta due protocolli di autorizzazione: MIT-MAGIC-COOKIE-1 e SUN-DES-1. Questi due protocolli utilizzano un meccanismo di controllo simile ma un tipo diverso di dati di autorizzazione. Il server può utilizzare un solo protocollo alla volta. Il protocollo di default di OpenWindows è MIT-MAGIC-COOKIE-1 con meccanismo di protezione riferito all'utente.

MIT-MAGIC-COOKIE-1

Il protocollo di autorizzazione MIT-MAGIC-COOKIE-1 è un prodotto sviluppato dal Massachusetts Institute of Technology. All'avvio del server viene creato un magic cookie per il server e per l'utente che ha avviato il sistema. Ad ogni richiesta di connessione, il client dell'utente invia il magic cookie al server come parte del pacchetto di connessione. Il magic cookie inviato viene confrontato con quello del server. Se i due magic cookie corrispondono, l'utente ottiene il diritto di accesso; in caso contrario l'accesso viene negato.

SUN-DES-1

Il protocollo di autorizzazione SUN-DES-1, sviluppato da Sun Microsystems, è basato su Secure RPC (Remote Procedure Call) e richiede un supporto DES (Data Encryption Software). L'informazione chiave per l'autorizzazione è il nome di rete dell'utente. Questo nome viene codificato e inviato al server come parte del pacchetto di connessione. Il server decodifica l'informazione e quindi, se riconosce il nome di rete, abilita la connessione.

Questo protocollo offre un livello di protezione superiore a quello del MIT-MAGIC-COOKIE-1. Il nome di rete del proprio sistema non può essere in alcun modo utilizzato da altri utenti per accedere al server, mentre è possibile che un altro utente utilizzi il proprio magic cookie.

Questo protocollo è disponibile solo nelle librerie di OpenWindows Versione 3 e successive. Non può essere utilizzato da applicazioni create con librerie statiche, in particolare Xlib, in ambienti precedenti a OpenWindows Versione 3.

Il paragrafo "Abilitazione dell'accesso con SUN-DES-1", in questo capitolo, spiega come autorizzare un altro utente ad accedere al proprio server aggiungendo il suo nome di rete alla lista degli accessi abilitati.

Modifica del protocollo di autorizzazione di default

Il protocollo di autorizzazione di default, MIT-MAGIC-COOKIE-1, può essere modificato per utilizzare SUN_DES-1, l'altro protocollo supportato, o per non utilizzare alcun meccanismo di controllo riferito all'utente. L'impostazione di default può essere modificata utilizzando le opzioni appropriate insieme al comando openwin. Ad esempio, per cambiare l'impostazione di default da MIT-MAGIC-COOKIE-1 a SUN-DES-1, avviare OpenWindows come segue: 

esempio% openwin -auth sun-des

Per avviare OpenWindows senza il meccanismo di accesso riferito all'utente, digitare la riga di comando con l'opzione -noauth:

esempio% openwin -noauth

Avvertenza - Avvertenza -

L'uso dell'opzione -noauth riduce la sicurezza del sistema. OpenWindows viene eseguito con il solo meccanismo di controllo riferito all'host, in quanto il server disattiva il meccanismo riferito all'utente. In questo modo, chiunque abbia accesso alle applicazioni di un dato sistema locale avrà accesso anche al relativo server.

Gestione degli accessi al server

Se OpenWindows non viene avviato con l'opzione -noauth (vedere "Modifica del protocollo di autorizzazione di default "), sono attivi sia il meccanismo di controllo riferito all'utente sia quello riferito all'host. Il server utilizza per primo il meccanismo riferito all'utente, e successivamente quello riferito all'host. Il protocollo riferito all'utente impostato nella configurazione di default è MIT-MAGIC-COOKIE-1, mentre al meccanismo riferito all'host è associata una lista vuota. Ciò significa che è effettivamente attivo solo il meccanismo orientato all'utente. L'opzione -noauth ordina al server di disabilitare il meccanismo di controllo orientato all'utente e inizializza la lista degli host aggiungendovi l'host locale.

Per cambiare il meccanismo di controllo degli accessi al server sono disponibili due programmi: xhost e xauth. Per maggiori informazioni, vedere le relative pagine man. Questi programmi accedono a due file binari creati dal protocollo di autorizzazione, i quali contengono dati relativi ad ogni sessione. Uno dei file è riservato al server per uso interno, mentre l'altro si trova nella directory $HOME dell'utente:

Il programma xhost permette di modificare la lista degli host con diritto di accesso al server. La lista può essere modificata con l'aggiunta o la cancellazione di altri host. Avviando il sistema con la configurazione di default -- con la lista di accesso degli host vuota -- e utilizzando xhost per aggiungere il nome di un sistema, di fatto si riduce il livello di sicurezza del sistema. Il server consentirà infatti l'accesso sia all'host inserito che a tutti gli utenti che specifichino il protocollo di autorizzazione di default. Per maggiori informazioni sul livello di protezione del meccanismo riferito all'host, vedere "Accesso riferito all'host".

Il programma xauth accede ai dati del protocollo di autorizzazione contenuti nel file .Xauthority del client. Per consentire ad altri utenti di accedere al server, perciò, si potranno estrarre questi dati dal file .Xauthority in modo che tali utenti li possano inserire nel loro file .Xauthority.

Il paragrafo "Abilitazione dell'accesso con MIT-MAGIC-COOKIE-1" contiene alcuni esempi relativi all'uso di xhost e xauth.

File di autorizzazioni dei client

Il file che contiene le autorizzazioni dei client è .Xauthority. I dati sono contenuti nella forma seguente: 

protcl_connessione  protcl_autorizzazione  dati_autorizzazione

Per default, .Xauthority contiene MIT-MAGIC-COOKIE-1 come protcl_autorizzazione e istruzioni relative alla sola visualizzazione locale come protcl_connessione e dati_autorizzazione. Ad esempio, il file .Xauthority dell'host generico host potrebbe contenere le righe seguenti: 

host:0          MIT-MAGIC-COOKIE-1    82744f2c4850b03fce7ae47176e75
hostlocale:0    MIT-MAGIC-COOKIE-1    82744f2c4850b03fce7ae47176e75
host/unix:0     MIT-MAGIC-COOKIE-1    82744f2c4850b03fce7ae47176e75

All'avvio dell'applicazione client, il sistema legge una riga corrispondente al protcl_connessione dal file .Xauthority e invia al server il protcl_autorizzazione e i dati_autorizzazione come parte del pacchetto di connessione. Nella configurazione di default, xhost restituisce liste di accesso vuote per gli host e dichiara abilitata l'autorizzazione di accesso.

Se il protocollo di autorizzazione di default è stato sostituito con SUN-DES-1, il file .Xauthority contiene SUN-DES-1 come protcl_autorizzazione e il nome di rete dell'utente come dati_autorizzazione. Il nome di rete si presenta come segue: 

unix.idutente@dominioNIS

Ad esempio, il file .Xauthority dell'host generico host può contenere le righe indicate nell'esempio seguente, dove unix.15339@EBB.Eng.Sun.COM è il nome di rete dell'utente indipendente dal sistema:

host:0         SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
hostlocale:0    SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
host/unix:0    SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

Nota -

Se non si conosce il proprio nome di rete o il nome di rete indipendente dal sistema, richiederlo all'amministratore di sistema.

Abilitazione dell'accesso con MIT-MAGIC-COOKIE-1

Se si utilizza il protocollo di autorizzazione MIT-MAGIC-COOKIE-1, per aggiungere un nuovo utente alla lista di accesso del server procedere come segue:

  1. Sul sistema che esegue l'applicazione server, eseguire xauth per estrarre in un file una riga corrispondente a nomehost:0.

    In questo esempio, nomehost è host e il file è xauth.info:

    myhost% /usr/openwin/bin/xauth nextract
- host:0 > $HOME/xauth.info

  2. Inviare il file contenente questa riga all'utente che ha richiesto l'accesso (usando Posta Elettronica, rcp o un altro metodo di trasferimento).

    Nota -

    L'invio del file contenente le informazioni di autorizzazione tramite posta elettronica è un metodo più sicuro rispetto all'uso di rcp. Se tuttavia si sceglie di utilizzare rcp, non collocare il file in una directory che sia facilmente accessibile ad altri utenti.

  3. L'utente ricevente dovrà inserire la riga nel proprio file .Xauthority.

    In questo esempio, l'utente inserisce xauth.info nel file .Xauthority dell'altro utente: 

    hostutente% /usr/openwin/bin/xauth nmerge - < xauth.info

    Nota -

    I dati_autorizzazione si riferiscono a una sessione specifica; ciò significa che sono validi solo per la sessione corrente del server.

Abilitazione dell'accesso con SUN-DES-1

Se si utilizza il protocollo di autorizzazione SUN-DES-1, per abilitare un nuovo utente ad accedere al server procedere come segue:

  1. Sul sistema che esegue il programma server, eseguire xhost per permettere al server di riconoscere il nuovo utente.

    In questo esempio, nuovo_utente viene abilitato ad accedere al sistema host:

    host% xhost + nuovo_utente@

  2. Il nuovo utente deve eseguire xauth per aggiungere la nuova istruzione al proprio file .Xauthority.

    In questo esempio, il nome di rete del nuovo utente indipendente dal sistema è unix.15339@EBB.Eng.Sun.COM. Si noti che questo comando deve essere scritto in un'unica riga, senza ritorni a capo. Dopo il simbolo di pipe, digitare uno spazio seguito dal resto del comando.

    hostutente% echo 'add host:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth

Esecuzione remota di applicazioni client, o esecuzione locale con un diverso nome utente

Le applicazioni client X utilizzano il valore della variabile d'ambiente DISPLAY per ricavare il nome del server al quale si devono collegare.

Per eseguire applicazioni client in modo remoto, o a livello locale con un diverso nome utente, procedere come segue:

  1. Sul sistema che esegue l'applicazione server, abilitare un nuovo utente.

    A seconda del protocollo di autorizzazione utilizzato, seguire la procedura descritta in "Abilitazione dell'accesso con MIT-MAGIC-COOKIE-1" o in "Abilitazione dell'accesso con SUN-DES-1".

  2. Impostare la variabile d'ambiente DISPLAY sul nome dell'host che esegue il server.

    In questo esempio, l'host è hostremoto:

    host% setenv DISPLAY hostremoto:0

  3. Eseguire il programma client come indicato nell'esempio. 

    host% programma_client&

    Il client verrà visualizzato sul sistema remoto hostremoto.