Figura 166.1: Il client chiede all'utente di identificarsi quando per la prima volta ciò viene richiesto dal server.
In precedenza, nel capitolo 95, è stato descritto il servizio HTTP, la configurazione di Apache in modo sintetico e l'utilizzo di un client in grado di accedere a tale servizio. In questo capitolo si vuole approfondire un po' la configurazione del server Apache. Per quanto riguarda le funzionalità di proxy di Apache, si può consultare il capitolo 180.
Prima di vedere i dettagli dell'impostazione del server, è il caso di ripassare in breve il suo funzionamento.
L'accesso al servizio HTTP avviene a partire da una parte del filesystem, che inizia dal cosiddetto DocumentRoot.
Il server non esegue la funzione chroot() in questa directory, e ciò consente di articolare le directory successive anche attraverso l'uso di collegamenti simbolici in posizioni precedenti alla directory DocumentRoot.
In linea di massima, ogni utente può realizzare una struttura personalizzata di documenti HTML, a partire dalla propria directory personale (home).
Il server è in grado di mettere in funzione dei programmi, detti CGI, per la gestione interattiva di pagine HTML contenenti dei moduli.
Nella configurazione di Apache si distinguono due directory che vengono definite attraverso un nome particolare; si tratta di ServerRoot e DocumentRoot. A queste se ne affiancano altre che derivano dalla configurazione consueta di questo server.
ServerRoot
La directory ServerRoot è il punto di origine dei file amministrativi di Apache. Viene dichiarata nel file httpd.conf, e gli altri file dichiarati all'interno di questo sono intesi essere collocati in posizione relativa a tale directory.
DocumentRoot
La directory DocumentRoot è il punto di origine dei documenti HTML.
Programmi CGI
Convenzionalmente, è opportuno collocare i programmi CGI in una posizione estranea alla struttura della directory DocumentRoot, per facilitare la configurazione della sua accessibilità. Per la stessa ragione è opportuno evitare di collocare programmi CGI nella struttura che ha origine da DocumentRoot.
Icone di sistema
Il server HTTP ha spesso la necessità di utilizzare icone per rappresentare delle informazioni in modo grafico, per esempio quando si visualizza il contenuto di una directory appartenente alla struttura di DocumentRoot. Sotto questo aspetto, è conveniente togliere tali icone dalla struttura dei documenti normali, perché non fanno parte di questi.
UserDir
In linea di massima è concesso agli utenti di creare una propria struttura di documenti ipertestuali. La directory di partenza di questi documenti viene definita UserDir, ed è relativa alla directory personale di questi utenti. È importante tenere presente che gli utenti hanno tale possibilità, per configurare opportunamente il server in modo che questi non possano creare danni.
Il servizio viene gestito dal demone httpd che può essere avviato direttamente dalla procedura di inizializzazione del sistema (Init), oppure può essere controllato da inetd. In questo secondo caso, quando si fanno delle modifiche alla configurazione, non occorre fare in modo che httpd le rilegga, perché è costretto a farlo ogni volta che viene risvegliato da inetd.
Quando httpd è indipendente da inetd (standalone), si può osservare la presenza di una serie di processi httpd discendenti da uno di origine.
# pstree [Invio]-p
init(1)-+-...
|
|-httpd(244)-+-httpd(859)
| |-httpd(860)
| |-httpd(861)
| |-httpd(862)
| `-httpd(863)
|-...
...
|
Per fare in modo che tutti questi processi rileggano i file di configurazione, basta inviare un segnale SIGHUP a quello principale; in questo caso il numero 244.
# kill [Invio]-HUP 244
# pstree [Invio]-p
init(1)-+-...
|
|-httpd(244)-+-httpd(901)
| |-httpd(902)
| |-httpd(903)
| |-httpd(904)
| `-httpd(905)
|-...
...
|
Come si può osservare, il processo httpd principale rimane attivo, mentre quelli inferiori vengono conclusi e riavviati (lo si vede dal numero PID). Attenzione però: se si invia un segnale di questo tipo al processo httpd dopo aver modificato la configurazione in modo errato, questo termina il suo funzionamento.
httpd.conf è il file di configurazione principale di Apache. La sua collocazione dipende dal modo in cui è stato compilato Apache, oppure dall'opzione -fhttpd. Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti. Inoltre, nel capitolo
180 viene trattata la configurazione di Apache per la gestione di una cache proxy, cosa che riguarda in modo particolare proprio questo file.
Alcune direttive sono importanti per definire se il demone httpd funziona in modo autonomo o meno, e in tal caso per sapere su quale porta deve restare in ascolto.
ServerType { standalone | inetd }
|
La direttiva ServerType permette di informare Apache sul modo in cui questo viene avviato: in modo autonomo o attraverso inetd.
*1*
ServerType standalone |
Nell'esempio si mostra la dichiarazione per il funzionamento autonomo (standalone) che corrisponde alla situazione più comune (e più opportuna).
Port <numero-porta> |
Si tratta dell'indicazione della porta (di solito è 80, corrispondente alla denominazione http), necessaria nel caso in cui il demone sia stato avviato in modo autonomo. Infatti, diversamente, è inetd a stare in ascolto della porta corrispondente al servizio http.
Port 80 |
Listen <numero-porta> |
Se httpd viene utilizzato in modo autonomo, è possibile fare in modo che stia in ascolto anche di un'altra porta, per mezzo della direttiva Listen.
Listen 80 Listen 8080 |
L'esempio mostra in che modo si possa indicare a httpd di stare in ascolto sia della porta 80 che della 8080; quest'ultima utilizzata normalmente per interrogare un server proxy.
HostnameLookups { on | off }
|
Permette di decidere se si intende annotare nei file delle registrazioni l'indirizzo numerico o il nome dei nodi che accedono al servizio. Attivando questa direttiva (on) si registrano i nomi corrispondenti. L'attivazione di questa è necessaria se si intendono definire dei limiti di accesso basati sul nome di dominio dei client, come si vede nell'esempio seguente:
HostnameLookups on |
Spesso, un nodo che offre un servizio HTTP può essere identificato attraverso degli alias al nome di dominio canonico. Nella configurazione è opportuno definire un nome corretto, che può corrispondere anche a un alias, purché sia valido. Nello stesso modo, è importante definire l'indirizzo di posta elettronica presso cui può essere raggiunto l'amministratore del servizio (webmaster).
ServerAdmin <email> |
La direttiva ServerAdmin permette di definire l'indirizzo di posta elettronica dell'amministratore del servizio. Generalmente si tratterà dell'utente fittizio webmaster che dovrebbe essere ridiretto automaticamente all'utente root dal sistema di gestione della posta elettronica.
ServerAdmin webmaster@dinkel.brot.dg |
L'utilità di utilizzare un indirizzo di posta elettronica specifico, sta nella facilità con cui poi si intende il contesto a cui fanno riferimento questi messaggi.
ServerName <nome-standard-del-server> |
Attraverso questa direttiva si può dichiarare espressamente il nome di dominio del server HTTP. Può trattarsi di un alias definito nel sistema DNS, ma quello che conta è che si tratti di un nome valido.
ServerName www.brot.dg |
L'esempio dichiara che il nome del nodo che offre il servizio è www.brot.dg, anche se magari il nome canonico di questo, secondo il DNS, è diverso. Quello che conta è che il sistema DNS sia in grado di risolvere anche questo nome qui dichiarato.
L'utilizzo di un servizio HTTP è qualcosa di prettamente anonimo, in quanto la natura di questo, per cui tutto si traduce in semplici richieste seguite da risposte, impedisce una gestione sensata di identificativi utente e delle password relative.
User { <utente> | #n }
|
Group { <gruppo> | #n }
|
Queste due direttive permettono di definire l'utente e il gruppo fittizio da abbinare agli accessi fatti al servizio. In pratica, quando si legge un file HTML o si interpella un programma CGI, lo si fa come se si fosse l'utente indicato da queste due direttive. Solitamente, per motivi di sicurezza, si utilizza l'utente e il gruppo nobody.
Se per qualche motivo si preferisce una notazione numerica, invece di indicare il nome dell'utente e del gruppo si può usare il numero UID e GID, preceduto dal simbolo #.
User nobody Group nobody |
Perché queste direttive possano funzionare, occorre che il demone httpd sia avviato con i privilegi dell'utente root, altrimenti non ha modo di eseguire il cambiamento di utente e gruppo, e può solo continuare a funzionare con i privilegi ottenuti all'avvio.
Il file httpd.conf contiene l'indicazione della directory ServerRoot, della posizione dei file delle registrazioni ed eventualmente anche degli altri file di configurazione.
ServerRoot <directory> |
Rappresenta la directory a partire dalla quale si diramano le informazioni sulla configurazione, sulla registrazione degli eventi e simili. Corrisponde solitamente a qualcosa come etc/httpd/. Potrebbe essere definita anche attraverso l'opzione -dhttpd.
ServerRoot /etc/httpd |
L'esempio mostra la posizione più conveniente di questa directory per aderire allo standard GNU/Linux sulla struttura del filesystem.
ResourceConfig <config-srm> |
AccessConfig <config-access> |
Le direttive mostrate servono per definire rispettivamente il nome e la collocazione del file di configurazione delle risorse e del file di configurazione degli accessi. Generalmente, i nomi e la collocazione di questi file non devono essere dichiarate espressamente, perché è sufficiente quanto risulta predefinito all'interno del programma stesso.
ResourceConfig conf/srm.conf AccessConfig conf/access.conf |
L'esempio mostra la dichiarazione esplicita dei nomi utilizzati per gli altri file di configurazione. Mancando l'indicazione di un percorso assoluto, si intende che debbano essere discendenti della directory ServerRoot.
ErrorLog <registro-degli-errori> |
TransferLog <registro-dei-trasferimenti> |
Queste direttive definiscono i nomi e la collocazione dei file delle registrazioni. Generalmente i percorsi indicati sono relativi, in tal caso si riferiscono alla directory ServerRoot come punto iniziale.
ErrorLog /var/log/httpd/error_log TransferLog /var/log/httpd/access_log |
L'esempio mostra la dichiarazione dei due file delle registrazioni, con un percorso assoluto: /var/log/httpd/.
PidFile <file-pid> |
Definisce il nome e la collocazione del file utilizzato per contenere il numero di processo del demone httpd principale, quando questo funziona in modo autonomo.
PidFile /var/run/httpd.pid |
L'esempio mostra l'indicazione del file /var/run/httpd.pid, con un percorso assoluto, in modo da non finire al di sotto della directory ServerRoot.
ScoreBoardFile <file-di-informazioni> |
Definisce il nome e la collocazione di un file contenente una serie di informazioni sul funzionamento corrente del server, necessarie al server stesso per la comunicazione tra processi.
ScoreBoardFile /var/run/apache_status |
L'esempio mostra l'indicazione del file /var/run/apache_status, con un percorso assoluto, in modo da non finire al di sotto della directory ServerRoot.
Il file srm.conf è il file di configurazione delle risorse di Apache. Viene letto subito dopo quello di configurazione del server. Definisce in particolare dove si trovino i documenti (le directory DocumentRoot e UserDir), gli alias di directory speciali e altre informazioni correlate. La sua collocazione dipende dal modo in cui è stato compilato Apache, oppure dalla direttiva ResourceConfig del file httpd.conf.
Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti.
La funzione principale di srm.conf è quello di definire la collocazione dei documenti ipertestuali, oltre ad altre informazioni di contorno.
DocumentRoot <directory-iniziale-documenti-html> |
La direttiva DocumentRoot dichiara la directory da cui si possono diramare i documenti HTML (per qualche motivo oscuro, è importante che non abbia la barra obliqua finale).
DocumentRoot /home/httpd/html |
L'esempio mostra il caso in cui la directory /home/httpd/html/ corrisponda all'inizio dei documenti HTML.
UserDir { <directory-iniziale-documenti-utenti> | DISABLED [<utente>] }
|
La direttiva UserDir dichiara la directory, relativa alla posizione di quella personale di ogni utente, all'interno della quale ognuno può collocare i propri documenti HTML personali. Si accede a questi utilizzando l'URI http://<host>/~<utente>.
UserDir public_html |
L'esempio mostra la dichiarazione tipica di questa direttiva e significa che ogni utente può creare la directory ~/public_html/ all'interno della quale collocare le proprie pagine.
Supponendo di accedere all'URI http://www.brot.dg/~tizio/elenco.html si fa riferimento effettivamente al file ~tizio/public_html/elenco.html. In questo modo, tra le altre cose, si evita di esporre l'intera directory personale dell'utente.
UserDir DISABLED |
L'esempio mostra in che modo possa essere impedito ai singoli utenti di creare le proprie pagine HTML nella loro directory personale.
|
Quando si concede agli utenti di realizzare le loro pagine HTML personali, occorre tenere presente che questo fatto può costituire un problema di sicurezza del sistema: un utente potrebbe creare un semplice collegamento simbolico verso un file o una directory che pur risultando leggibile a tutti gli utenti, non avrebbe dovuto essere accessibile al mondo intero. A questo si può porre rimedio, ma per farlo occorre intervenire sul file |
UserDir DISABLED root |
A partire dalla versione 1.3 di Apache è possibile specificare a quali utenti vietare la costruzione di pagine HTML personali, come nell'esempio mostrato, in cui questo viene impedito all'utente root.
Quando si tenta di accedere a una directory, invece che a un file particolare, si ottiene l'indice del contenuto, come se si trattasse del protocollo FTP, oppure il contenuto di una pagina predefinita.
DirectoryIndex <file-indice>... |
Quando si accede a una directory invece che a un file specifico, se questa contiene un file tra quelli elencati nella direttiva DirectoryIndex viene restituito quel file, invece del semplice elenco del contenuto. Solitamente si utilizza il nome index.html. Questo meccanismo permette di mascherare il contenuto effettivo della directory, oltre che di guidare l'utente del servizio in modo che non si perda in una miriade di file.
DirectoryIndex index.html index.htm |
L'esempio dichiara due file (index.html e index.htm) come possibili indici da utilizzare quando si fa riferimento a una directory senza indicare un file specifico.
FancyIndexing { on | off }
|
La direttiva FancyIndexing permette di definire se, quando viene restituito l'elenco del contenuto di una directory, si vuole una rappresentazione a icone, oppure se si vuole un testo puro e semplice. La parola chiave on attiva la visualizzazione a icone; off la disabilita.
FancyIndexing on |
AddIconByEncoding (<sigla>,<file-icona>) <tipo-codifica>... |
Questa direttiva abbina un'icona a uno o più tipi di codifica. La sigla rappresenta una stringa da utilizzare al posto dell'icona quando non è possibile la sua rappresentazione (per esempio se si usa il navigatore Lynx).
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip |
AddIconByType (<sigla>,<file-icona>) <tipo-MIME>/<sottotipo> |
Questa direttiva abbina un'icona a un tipo e sottotipo MIME, eventualmente utilizzando l'asterisco nel sottotipo per includerli tutti. La sigla rappresenta una stringa da utilizzare al posto dell'icona quando non è possibile la sua rappresentazione.
AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* |
AddIcon <file-icona> <estensione>... |
Questa direttiva abbina un'icona a una o più estensioni del nome dei file.
AddIcon /icons/binary.gif .bin .exe AddIcon /icons/binhex.gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ^^DIRECTORY^^ AddIcon /icons/blank.gif ^^BLANKICON^^ |
DefaultIcon <file-icona> |
Questa direttiva permette di definire un'icona predefinita per i file che non rientrano in una classificazione diversa.
DefaultIcon /icons/unknown.gif |
IndexIgnore <modello-da-ignorare>... |
Quando si consente di accedere a una directory visualizzandone il contenuto (perché manca il file index.html o equivalente), si può fare in modo che alcuni file non appaiano in elenco. Utilizzando questa direttiva, si possono indicare i modelli di file da non includere. Per questo si possono usare i caratteri jolly consueti (punto interrogativo e asterisco).
IndexIgnore */.??* *~ *# */HEADER* */README* */RCS |
L'esempio mostra l'esclusione dall'elenco di:
tutti i file che iniziano con un punto e sono lunghi almeno tre caratteri, perché si vuole continuare a includere il riferimento alla directory precedente;
tutti i file che terminano con il simbolo tilde, che sono solitamente delle copie di sicurezza di versioni precedenti;
tutti i file che terminano con il simbolo #, dal momento che anche questi sono generalmente copie di sicurezza di versioni precedenti;
tutti i file il cui nome inizia per HEADER o README, perché hanno un ruolo speciale;
il file RCS.
HeaderName <file-readme-iniziale> |
ReadmeName <file-readme-finale> |
Attraverso queste due direttive si possono specificare i nomi di file, il cui contenuto si vuole sia incluso nell'elenco della directory. Per la precisione, la direttiva HeaderName specifica il nome di un file da mettere prima dell'elenco; la direttiva ReadmeName specifica il nome di un file da mettere dopo l'elenco. L'esempio permette di chiarire altri dettagli.
HeaderName HEADER ReadmeName README |
In questo caso, viene cercato prima il file HEADER.html. Se viene trovato, viene incluso all'inizio dell'elenco della directory, mantenendo la formattazione HTML. Se manca, ma esiste il file HEADER, questo viene incluso in modo testuale. La stessa cosa vale per il file README.html o soltanto README, con la differenza che questo viene incluso alla fine, dopo l'elenco.
Il server ha bisogno di conoscere il tipo di file che si preleva per sapere come comportarsi, e soprattutto per poterlo comunicare al client che lo ha richiesto. Questo si ottiene attraverso la configurazione dei tipi MIME, ma è pur sempre necessario specificare il tipo predefinito, quando non si riesce a determinarlo altrimenti.
DefaultType <MIME-type>... |
Permette di definire il tipo MIME predefinito di un documento per il quale non si riesca a identificare diversamente. Di solito questo valore predefinito è text/plain.
DefaultType text/plain |
AddType <tipo>/<tipo> <estensione> |
Con questa direttiva si possono aggiungere dei tipi MIME senza intervenire nel file di definizione di questi, mime.types. Generalmente non è conveniente intervenire in questo modo; è sempre meglio utilizzare il file dei tipi MIME.
AddEncoding <tipo-di-compressione> <estensione> |
Questa direttiva permette di abbinare un'estensione a un tipo di codifica. Ciò permette ad alcuni client di sapere come gestire tali dati.
AddEncoding x-compress Z AddEncoding x-gzip gz |
L'esempio mostra la configurazione tipica, che serve a informare i client quando viene inviato loro un file compresso con compress o con gzip.
Per evitare confusione, e per motivi di sicurezza, è opportuno dichiarare alcune directory speciali in forma di alias.
Alias <directory-fasulla> <directory-reale> |
Questo tipo di direttiva, che può essere ripetuta, permette di definire delle directory in posizioni diverse da quelle reali. La directory fasulla fa riferimento a una directory indicata nell'indirizzo URI richiesto, e quella reale indica la directory effettiva nel filesystem.
Alias /icons/ /home/httpd/icons/ |
L'esempio mostra la dichiarazione di una directory cui si accede attraverso l'alias /icons/. In pratica, tutte le volte che viene richiesta una risorsa contenuta nella directory /icons/, questa verrà prelevata dalla directory reale /home/httpd/icons/.
La dichiarazione dell'alias /icons/ è molto importante nella consuetudine, dal momento che si tratta del riferimento alla directory contenente le icone utilizzare per la visualizzazione degli indici. Si è visto in un'altra sezione la dichiarazione dell'abbinamento delle icone a seconda dell'estensione dei file, come nell'esempio seguente, dove si fa riferimento a questo alias.
... AddIcon /icons/binary.gif .bin .exe ... |
ScriptAlias <directory-fasulla> <directory-reale> |
Funziona come la direttiva Alias, ma si riferisce ai programmi CGI. Generalmente, i programmi CGI dovrebbero essere collocati esclusivamente all'interno di directory dichiarate attraverso questa direttiva, per non rischiare di creare problemi di sicurezza del sistema.
ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/ |
È possibile stabilire un comportamento particolare in base all'estensione dei file. Con questo si intende qualcosa di diverso dalla semplice lettura e invio al client che ne fa richiesta. La sintassi generale è la seguente:
AddHandler <nome-dell'azione> <estensione> |
Il nome dell'azione definisce un tipo preciso di operazione da abbinare ai file che contengono l'estensione indicata.
AddHandler cgi-script <estensione> |
Questa direttiva, usata in questo modo, permette di abbinare a un'estensione l'esecuzione automatica come programma CGI. È decisamente sconsigliabile di permettere l'utilizzo di programmi CGI al di fuori della directory dichiarata con la direttiva ScriptAlias. L'esempio seguente mostra questa direttiva commentata opportunamente per sicurezza.
# AddHandler cgi-script .cgi |
È possibile definire il nome di un file di configurazione che, se presente, serve per definire l'accesso alla directory in cui si trova. Il nome predefinito di questo è .htaccess. Per questo si utilizza la direttiva AccessFileName, come nell'esempio seguente:
AccessFileName .htaccess |
In occasione di determinate situazioni errore, il server emette delle segnalazioni di errore. Questi messaggi possono essere riscritti in forma di file HTML o di programma CGI. La direttiva per controllare questi messaggi ha tre sintassi possibili.
ErrorDocument <n-errore> <file-alternativo> |
ErrorDocument <n-errore> <uri-esterno> |
ErrorDocument <n-errore> "<messaggio> |
Nel primo caso, l'ultimo argomento è un file HTML o un programma CGI; nel secondo si tratta di un URI esterno; nel terzo si tratta di una stringa, e viene riconosciuta come tale perché inizia con gli apici doppi ("). La stringa non deve essere terminata, a meno di volere fare apparire gli apici doppi finali.
ErrorDocument 500 "Errore del server www. |
L'esempio mostra il caso in cui si voglia fare apparire una stringa particolare in occasione del verificarsi dell'errore 500.
ErrorDocument 404 /documento_mancante.html |
In questo caso, in occasione dell'errore 404, viene inviato al client il file documento_mancante.html che conterrà qualche utile suggerimento per l'utente.
ErrorDocument 404 /cgi-bin/documento_mancante.pl |
Questa è una variante dell'esempio precedente, in cui, invece di inviare un file HTML viene eseguito un programma CGI, /cgi-bin/documento_mancante.pl. Ciò può essere utile per comporre una risposta personalizzata, utilizzando le informazioni cui può accedere il programma stesso.
ErrorDocument 404 http://roggen.brot.dg/cgi-bin/documento_mancante.pl |
Questa è una variante dell'esempio precedente, in cui si fa riferimento a una risorsa contenuta in un URI esterno al server in cui si manifesta il problema.
access.conf è il file di configurazione globale che permette di controllare l'accesso alle directory del sistema. La sua sintassi è diversa da quella degli altri due file di configurazione già visti. In particolare, oltre a normali direttive, si utilizzano dei delimitatori simili a marcatori HTML che permettono di definire il contesto a cui si riferiscono le direttive contenute. Più precisamente si parla si sezioni.
Le sezioni del file di configurazione degli accessi hanno una forma simile a quella seguente:
<Nome ...> ... </Nome> |
Nel marcatore che ne dichiara l'apertura possono apparire delle opzioni; nella parte compresa tra l'apertura e la chiusura si inseriscono delle direttive riferite a quella sezione particolare. A seconda del contesto, una sezione può contenere anche la dichiarazione di altre sezioni in modo annidato.
Le sezioni Directory raccolgono le direttive di controllo per una particolare directory e per quelle successive. La direttiva di apertura, ovvero il marcatore <Directory>, deve contenere l'indicazione della directory a cui si riferiscono le direttive della sezione, eventualmente usando anche i caratteri jolly (* e ?) o le espressioni regolari estese.
<Directory /home/httpd/html> Options Indexes FollowSymLinks </Directory> |
Questo esempio è il più comune, e dichiara una sezione riferita alla directory /home/httpd/html/.
<Directory "^/home/httpd/html/.*/[0-9]{3}">
Options Indexes FollowSymLinks
</Directory>
|
Questo esempio ulteriore, attraverso un'espressione regolare, dichiara una sezione riferita a tutte le directory discendenti di /home/httpd/html/ che iniziano con tre cifre numeriche.
---------
Quando una sezione si riferisce a una porzione già presa in considerazione da un'altra analoga, conviene che queste appaiano in una sequenza tale da porre prima le sezioni generali e dopo quelle più particolareggiate, come nell'esempio seguente:
<Directory /> AllowOverride None </Directory> ... <Directory /home/httpd/html> AllowOverride All </Directory> |
Di seguito sono descritte alcune delle direttive che possono essere usate all'interno della sezione Directory.
Options [+|
|
La direttiva Options permette di definire alcune opzioni in forma di parole chiave. La tabella
166.1 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.
| Parola chiave | Significato |
| None | Disabilita tutto. |
| All | Abilita tutte le opzioni. |
| FollowSymLinks | Abilita l'uso di collegamenti simbolici. |
| SymLinksIfOwnerMatch | Abilita l'uso di collegamenti simbolici solo se il proprietario coincide. |
| ExecCGI | Permette l'esecuzione dei programmi CGI. |
| Indexes | Permette di ottenere il listato del contenuto. |
| Includes | SSI è permesso. |
| IncludesNOEXEC | SSI è permesso in parte. |
Options nella sezione Directory.
Generalmente, se più direttive Options possono applicarsi alla stessa directory, quella riferita alla directory più specifica si sostituisce completamente alle altre. Tuttavia, se tutte le opzioni vengono precedute dal segno + o -+ vengono aggiunte; quelle precedute dal segno -
L'esempio seguente mostra la semplice dichiarazione della directory /home/httpd/html/ (corrispondente a DocumentRoot), in cui è consentito visualizzare il listato del contenuto e seguire i collegamenti simbolici.
<Directory /home/httpd/html> Options Indexes FollowSymLinks </Directory> |
AllowOverride <opzione>... |
La direttiva AllowOverride permette di definire quali opzioni possono essere scavalcate dalle dichiarazioni particolari contenute nei file di accesso delle singole directory (.htaccess). La tabella
166.2 ne riporta l'elenco. In particolare, le opzioni None e All vanno usate da sole.
| Parola chiave | Significato |
| None | Impedisce che qualunque direttiva venga scavalcata. |
| All | Permette che siano scavalcate tutte le direttive. |
| Options | Permette l'uso della direttiva Options. |
| Limit | Permette l'uso di direttive di controllo sugli accessi. |
| AuthConfig | Permette l'uso di direttive di autorizzazione. |
| FileInfo | Permette l'uso di direttive di controllo del tipo di documento. |
| Indexes | Permette l'uso di direttive di controllo sul listato delle directory. |
AllowOverride nella sezione Directory.
L'esempio seguente mostra la semplice dichiarazione della directory /home/httpd/html/ (corrispondente a DocumentRoot), in cui è consentito visualizzare il listato del contenuto e seguire i collegamenti simbolici. Per questa directory (e per le successive) non è possibile scavalcare alcuna direttiva utilizzando i file .htaccess.
<Directory /home/httpd/html> Options Indexes FollowSymLinks AllowOverride None </Directory> |
Attraverso una serie di direttive è possibile definire l'autorizzazione all'accesso alla directory, fornendo un nominativo e una password. Questi nominativi e le password cifrate relative devono essere contenuti in un file creato con un programma apposito, htpasswd, ed è necessario che non coincidano con nominativi e password già utilizzati per accedere al sistema. Infatti, il programma client memorizza queste informazioni la prima volta che vengono inserite, e quindi le fornisce automaticamente a ogni richiesta.
*2*
A fianco del file di utenti e password, si può creare un file di gruppi che serve solo a facilitare la definizione delle autorizzazioni, quando si vuole fare riferimento a un intero gruppo di utenti, senza doverli elencare.
---------
AuthName <nome> |
La direttiva AuthName permette di definire un nome per identificare il contesto dell'autorizzazione. Questa descrizione viene data all'utente quando gli viene richiesto di inserire il nominativo e la password, in modo da permettergli di distinguere tra autorizzazioni diverse che possono richiedere un'identificazione differente.
AuthType Basic |
Specifica il tipo di autorizzazione. In pratica è disponibile solo il tipo Basic ed è obbligatorio l'utilizzo di questa direttiva.
AuthUserFile <file-di-utenti-e-password> |
Specifica un file da utilizzare come elenco di utenti e password. Questo file viene creato e aggiornato utilizzando il programma htpasswd.
AuthGroupFile <file-dei-gruppi> |
Specifica un file da utilizzare come elenco di gruppi abbinati agli utenti. Non contiene password e viene creato in modo manuale.
require user <utente>... |
require group <gruppo>... |
require valid
|
Una di queste direttive stabilisce la necessità dell'identificazione attraverso un nominativo-utente e una password. Nel primo caso si indicano precisamente quali utenti possono accedere, nel secondo quali gruppi di utenti, e nel terzo si afferma semplicemente che possono accedere tutti.
L'esempio seguente definisce un accesso ristretto e condizionato al riconoscimento degli utenti. In particolare però, solo gli utenti tizio, caio e semproni possono accedere.
<Directory /home/httpd/html/riservato> AllowOverride None Options Indexes AuthName Informazioni riservate AuthType Basic AuthUserFile /etc/httpd/conf/.htpasswd AuthGroupFile /etc/httpd/conf/.htgroup require user tizio caio semproni </Directory> |
In origine, queste direttive erano consentite solo nella sezione Limit. Se vi appaiono fuori, indicano che si riferiscono a qualunque metodo di accesso. Quando si utilizzano queste direttive, se si intende fare uso di nomi di dominio è indispensabile avere attivato la risoluzione dei nomi di dominio attraverso la direttiva HostnameLookups nel file httpd.conf.
---------
order allow,deny |
order deny,allow |
order mutual
|
Specifica l'ordine in cui devono essere prese in considerazione le direttive deny e allow. Quando si specifica la parola chiave mutual, si intende che possono accedere solo i nodi che appaiono nella lista -failureallow e non appaiono in quella deny.
deny from { all | <host>... }
|
Impedisce l'accesso da parte dei nodi elencati. Se si usa la parola chiave all si impedisce a tutti di accedere. i nodi possono essere indicati attraverso il nome di dominio, completo o parziale, e attraverso l'indirizzo numerico, completo o parziale.
allow from { all | <host>... }
|
Consente l'accesso da parte dei nodi elencati. Se si usa la parola chiave all si consente a tutti di accedere. i nodi possono essere indicati attraverso il nome di dominio, completo o parziale, e attraverso l'indirizzo numerico, completo o parziale.
L'esempio seguente stabilisce il blocco all'accesso da parte degli utenti del dominio mehl.dg, a partire dalla directory dichiarata nell'apertura della sezione Directory.
<Directory /home/httpd/html/polenta> AllowOverride None Options Indexes order allow,deny allow from all deny from .mehl.dg </Directory> |
L'esempio seguente, invece, concede solo al dominio mehl.dg di poter accedere.
<Directory /home/httpd/html/polenta> AllowOverride None Options Indexes order deny,allow deny from all allow from .mehl.dg </Directory> |
L'esempio seguente è una variante del precedente, in cui si utilizza anche l'indicazione di una sottorete in forma di indirizzo numerico.
<Directory /home/httpd/html/polenta> AllowOverride None Options Indexes order deny,allow deny from all allow from .mehl.dg 192.168.2. </Directory> |
Le sezioni Limit sono usate per racchiudere un gruppo di direttive di controllo di accesso, che riguardano solo i metodi specificati. I metodi di accesso in questione sono, per esempio, GET e POST.
<Directory /home/httpd/html/riservato> AllowOverride None Options Indexes AuthName Informazioni riservate AuthType Basic AuthUserFile /etc/httpd/conf/.htpasswd AuthGroupFile /etc/httpd/conf/.htgroup <Limit GET POST> require valid-user </Limit> </Directory> |
L'esempio mostra che per la directory specificata è richiesta l'autenticazione solo in caso di utilizzo dei metodi GET e POST.
---------
Quando si vuole che le direttive di controllo di accesso riguardino tutti i metodi di accesso, non si usa la sezione Limit.
In linea di massima, la sezione Limit può contenere ogni direttiva, a esclusione della dichiarazione ulteriore di sezioni Directory e Limit annidate. In pratica, si utilizzano solo direttive per cui abbia senso porre un limite basato sul metodo di accesso. Generalmente ha significato l'utilizzo delle direttive indicate nella tabella
166.3.
| Direttiva | Descrizione |
| require | Utenti che possono accedere attraverso autenticazione. |
| order | Ordine di valutazione delle direttive deny e allow. |
| deny | Specifica i nodi a cui viene negato l'accesso. |
| allow | Specifica i nodi a cui viene concesso l'accesso. |
Limit.
Le sezioni Location raccolgono le direttive di controllo per un URI particolare. Si tratta di qualcosa molto simile alla sezione Directory, con la differenza che il riferimento è fatto all'URI piuttosto che alla directory del filesystem effettivo.
Questa sezione viene usata prevalentemente per abilitare l'accesso allo stato del server attraverso l'indicazione di un URI, da parte di un particolare indirizzo autorizzato.
<Location /status> SetHandler server-status order deny,allow deny from all allow from dinkel.brot.dg </Location> |
Nell'esempio viene concesso al nodo dinkel.brot.dg di accedere all'URI /status cui è abbinata la generazione e la restituzione di informazioni sul sistema. Il risultato potrebbe essere qualcosa di simile a quello che segue.
Apache Server Status for dinkel.brot.dg Current Time: Sun Sep 28 14:00:47 1997 Restart Time: Sun Sep 28 14:00:28 1997 Server uptime: 19 seconds Total accesses: 0 - Total Traffic: 0 B CPU Usage: u0 s0 cu0 cs0 0 requests/sec - 0 B/second - Scoreboard: K___W__........................................... .................................................. .................................................. Key: "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup, "L" Logging 2 requests currently being processed, 5 idle servers Srv PID Acc M CPU SS Conn Child Slot Host Request 0 8449 0/0/0 K 0.00 10 0.0 0.00 0.00 4 8453 0/0/0 W 0.00 0 0.0 0.00 0.00 dinkel.brot.dg GET /status HTTP/1.0 ------------------------------------------------------------------------ Srv Server number PID OS process ID Acc Number of accesses this connection / this child / this slot M Mode of operation CPU CPU usage, number of seconds SS Seconds since beginning of most recent request Conn Kilobytes transferred this connection Child Megabytes transferred this child Slot Total megabytes transferred this slot |
I file .htaccess possono essere usati per definire delle configurazioni specifiche riferite alla directory in cui si trovano. Non è necessario il loro utilizzo; si tratta solo di una possibilità, che peraltro deve essere controllata attraverso la direttiva AllowOverride nel file access.conf. In linea di massima, i file .htaccess possono contenere le direttive elencate nella tabella
166.4
| Direttiva | Descrizione |
| Options | Opzioni varie. |
| DefaultType | Definisce il tipo e il sottotipo MIME predefinito per la directory. |
| ErrorDocument | Ridefinisce la risposta in caso si verifichino condizioni di errore. |
| AuthName | Nome o descrizione di una zona soggetta ad autenticazione. |
| AuthType | Definizione del tipo di autenticazione. |
| require | Dichiarazione degli utenti autorizzati all'autenticazione. |
| order | Ordine di valutazione delle direttive deny e allow. |
| deny | Specifica i nodi a cui viene negato l'accesso. |
| allow | Specifica i nodi a cui viene concesso l'accesso. |
.htaccess.
Dalla descrizione dei file di configurazione di Apache si possono intuire i punti su cui agire per cercare di ottenere un servizio HTTP relativamente «sicuro». Vale comunque la pena di sottolineare alcuni punti.
Il demone httpd viene avviato normalmente con i privilegi dell'utente root, quindi, attraverso delle opportune chiamate di sistema, httpd cambia questi privilegi portandoli a quelli dell'utente e del gruppo specificati con le direttive User e Group del file httpd.conf.
È molto importante che l'utente e il gruppo corrispondano a nobody, dove questo utente fittizio deve corrispondere idealmente al «perfetto sconosciuto» che accede al sistema. In questa ottica devono poi essere regolati i permessi delle directory.
I file amministrativi di Apache, cioè quelli di configurazione e di registrazione degli eventi, non devono essere accessibili in scrittura da parte degli utenti comuni (di qualunque tipo siano, escluso root). Nello stesso modo, non devono essere modificabili le directory che li contengono.
I file che compongono i documenti ipertestuali devono essere accessibili solo in lettura agli utenti comuni, così le directory non devono essere modificabili, eccetto i permessi che può avere l'utente root.
È consigliabile utilizzare la direttiva SymLinksIfOwnerMatch per evitare brutti scherzi da parte degli utenti che hanno la possibilità di creare documenti HTML a partire dalla loro directory personale.
È bene evitare di permettere l'utilizzo di programmi CGI al di fuori della directory definita con la direttiva ScriptAlias nel file srm.conf.
È opportuno evitare di concedere agli utenti comuni di modificare le impostazioni attraverso i file .htaccess. Si ottiene questo con la direttiva AllowOverride None.
Segue un esempio molto semplice della configurazione del file access.conf.
# Prima si impedisce l'accesso alla radice del filesystem.
<Directory />
AllowOverride None
Options None
order deny,allow
deny from all
</Directory>
# Si definisce la directory DocumentRoot.
<Directory /home/httpd/html>
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
order deny,allow
allow from all
</Directory>
# Si concede di accedere alle directory personali degli utenti.
<Directory /home/*/public_html>
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
order deny,allow
allow from all
</Directory>
# Si concede l'esecuzione ai programmi CGI che si trovano a
# partire dalla directory predisposta per questo.
<Directory /home/httpd/cgi-bin>
AllowOverride None
Options ExecCGI
order deny,allow
allow from all
</Directory>
# Si concede l'accesso alla directory contenente le icone di sistema.
<Directory /home/httpd/icons>
AllowOverride None
Options None
order deny,allow
allow from all
</Directory>
# Abilita la lettura dello stato del server.
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .brot.dg
</Location>
|
Come si può osservare, non è stato consentito in alcun caso di utilizzare i file .htaccess e i collegamenti simbolici sono tollerati se il proprietario del collegamento equivale a quello del file o della directory di destinazione. Inoltre sono state prese le misure seguenti:
è impedito l'accesso a partire dalla directory radice del filesystem, e questo obbliga a dichiarare l'accesso alle directory successive;
viene concesso l'accesso alla directory da cui si diramano i documenti ipertestuali;
viene concesso espressamente l'accesso alle directory personali degli utenti;
i programmi CGI possono essere eseguiti solo nella directory preposta a questo, e non risulta leggibile il suo contenuto;
l'accesso alla directory contenente le icone utilizzate da Apache è stato dichiarato espressamente, altrimenti sarebbero risultate inaccessibili a causa del divieto iniziale sulla directory radice;
è stata abilita la lettura dello stato del server, concedendo l'accesso solo al dominio brot.dg.
Il sistema di autenticazione del server permette di consentire l'accesso a determinate directory solo a utenti identificati in base a un nome e a una password. È molto importante capire come funziona il meccanismo, per non farsi delle illusioni sull'efficienza del sistema.
Figura 166.1:
Il client chiede all'utente di identificarsi quando per la prima volta ciò viene richiesto dal server.
La prima volta che l'utente accede, il client gli presenta la richiesta di inserire il nominativo e la password, poi tutto funziona normalmente. Però, essendo il protocollo HTTP privo di stato, non si instaura una connessione vera e propria; ogni richiesta è una connessione a parte, e ognuna di queste richiede un'autenticazione. In effetti, il client memorizza i dati inseriti dall'utente e continua a fornirli al server. Questo fatto ha due implicazioni: la password viaggia continuamente attraverso la rete; più utenti possono accedere simultaneamente da postazioni differenti, utilizzando la stessa identificazione e password. Sotto questo aspetto, è importante che le password che si adoperano per queste cose non abbiano alcun nesso con quelle «serie».
Per gestire questo tipo di autenticazione, occorre generare un file di utenti e password, e possibilmente anche un file di gruppi. Si utilizza il programma htpasswd che normalmente fa parte del pacchetto di Apache.
htpasswd [
|
htpasswd crea o aggiorna un file di utenti e password per l'autenticazione degli accessi a directory protette con il server Apache.
L'opzione -c
# htpasswd [Invio]-c passwd tizio
Adding password for tizio. New password: |
Viene inserita la password seguita da [Invio].
Re-type new password: |
Viene reinserita la password seguita da [Invio] e si ottiene il file passwd nella directory corrente.
# cat passwd[Invio]
tizio:njHIUkjjJLKn |
Il file contiene solo i nomi degli utenti e le password cifrate relative.
# htpasswd passwd caio[Invio]
Quando si aggiungono utenti, non si utilizza l'opzione -c
# htpasswd passwd caio[Invio]
Lo stesso programma può essere usato per modificare la password di un utente già registrato.
Per facilitare la gestione di utenti che utilizzano l'autenticazione per accedere a directory protette, è possibile realizzare dei raggruppamenti e inserirli in un file senza password. Il formato del file è molto semplice: ogni record è costruito secondo la sintassi seguente:
<gruppo>: <utente>... |
Quindi, i nominativi dei vari utenti sono separati da uno spazio, come nell'esempio seguente:
primo: tizio caio semproni secondo: cane gatto topo |
Nell'esempio sono dichiarati due gruppi: primo e secondo. A primo appartengono gli utenti tizio, caio e semproni; a secondo appartengono gli utenti cane, gatto e topo.
La configurazione delle directory che devono essere accessibili solo attraverso un'autenticazione, avviene nel file access.conf in una sezione Directory. Sono indispensabili le direttive AuthName, AuthType e AuthUserFile con cui si dà un nome all'autenticazione, si definisce il tipo e si indica il nome del file degli utenti e password. La direttiva AuthGroupFile serve solo se si intende fare riferimento a gruppi di utenti.
<Directory /home/httpd/html/riservato> AllowOverride None Options Indexes AuthName Informazioni riservate AuthType Basic AuthUserFile /etc/httpd/conf/passwd AuthGroupFile /etc/httpd/conf/group require valid-user </Directory> |
La direttiva require stabilisce a chi, tra gli utenti che sono dichiarati nel file di utenti e password, sia concesso di accedere. La parola chiave valid rappresenta tutti gli utenti che siano stati previsti. In alternativa possono essere elencati gli utenti a cui concedere l'accesso, come nell'esempio seguente;
-user
... require user tizio caio semproni ... |
oppure si può indicare il nome di uno o più gruppi.
... require group primo terzo quinto ... |
Solo nell'ultimo caso è necessario predisporre e dichiarare la posizione del file dei gruppi.
Apache è in grado di gestire diversi siti virtuali, indipendenti, sullo stesso elaboratore. In pratica, si distinguono diverse directory per le pagine HTML (diverse directory DocumentRoot), e ognuna di queste viene selezionata in base al nome di dominio utilizzato per accedere al servizio.
Evidentemente, per arrivare a questo risultato, occorre che lo stesso elaboratore sia accessibile utilizzando nomi di dominio differenti: si va dall'attribuzione di un semplice alias all'interno del DNS (i record CNAME), fino alla sovrapposizione di indirizzi IP differenti sulle stesse interfacce (con la conseguente attribuzione di nomi di dominio differenti). A proposito della gestione del DNS, si vedano i capitoli
82 e
83.
Quanto visto su Apache fino a questo punto, riguarda la gestione di un unico sito: quello «reale». Si osservi in particolare che la direttiva DocumentRoot viene inserita nel file srm.conf. Per definire dei siti virtuali alternativi si interviene nel file httpd.conf, attraverso delle sezioni simili a quelle del file access.conf:
<VirtualHost <nome-di-dominio> >
<direttiva-specifica>
...
</VirtualHost>
|
In pratica, all'interno del marcatore di apertura dell'ambiente VirtualHost si inserisce il nome del sito virtuale a cui si fa riferimento, e all'interno della sezione si inseriscono le direttive specifiche per questo sito.
<VirtualHost prova.brot.dg>
ServerAdmin webmaster@prova.brot.dg
DocumentRoot /home/httpd/html2
ServerName prova.brot.dg
ErrorLog logs/prova.brot.dg-error_log
TransferLog logs/prova.brot.dg-access_log
</VirtualHost>
|
L'esempio mostra la predisposizione del sito virtuale prova.brot.dg. All'interno della sezione si vedono le dichiarazioni:
dell'indirizzo di posta elettronica dell'amministratore, con la direttiva ServerAdmin;
della directory di partenza delle pagine HTML, con la direttiva DocumentRoot;
del nome di dominio corretto per raggiungere il sito virtuale, con la direttiva ServerName;
dei percorsi completi dei file delle registrazioni, con le direttive ErrorLog e TransferLog.
È il caso di osservare la stranezza per la quale la direttiva DocumentRoot può apparire nella sezione VirtualHost all'interno del file httpd.conf, mentre per il sito reale si usa il file srm.conf.
Nel momento in cui si dichiara l'utilizzo di una nuova directory per i dati (le pagine HTML), ci si deve preoccupare anche di configurare l'accesso a tale directory. Questo si fa nel modo solito all'interno del file access.conf. Seguendo l'esempio mostrato, potrebbe essere necessario aggiungere la sezione seguente:
<Directory /home/httpd/html2> Options Indexes SymLinksIfOwnerMatch AllowOverride None order deny,allow allow from all </Directory> |
Apache
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) Quando httpd viene controllato da inetd, per ogni richiesta bisogna aspettare l'avvio del demone. Ciò genera un certo ritardo nelle risposte e può essere giustificato da particolari esigenze di sicurezza che si possono attuare solo in questo modo.
2.) È bene ricordare che il protocollo HTTP è privo di stato, per cui a ogni richiesta si ricomincia da capo.