Apache non seguirà i collegamenti simbolici (403 Proibito)

90

Ho qualche problema con la configurazione di Apache su Ubuntu. Ho seguito questa guida .

# /usr/sbin/apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built:   Feb 22 2011 18:33:02

La mia directory pubblica, / var / www, può servire ed eseguire con successo le pagine PHP che vi sono inserite. Tuttavia, voglio creare un collegamento simbolico in / var / www che punti a una directory nella mia cartella home e servire le pagine lì.

[root /var/www]# ll
total 36
drwxr-xr-x  3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx  1 root root   16 2011-09-11 13:21 about -> /root/site/about

Quando provo ad accedere a / informazioni su sul browser, ottengo 

Forbidden

You don't have permission to access /about on this server.

Per quanto ne so, ho dato privilegi sufficienti ai file che voglio servire:

[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume

Sono a conoscenza dell'opzione FollowSymLinks e credo che sia impostata nel mio file / etc / apache2 / sites-enabled / 000-default:

DocumentRoot /var/www
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>
<Directory /var/www/>
    Options FollowSymLinks Indexes MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
</Directory>

Qualche idea su cosa potrei perdermi?

apache  configuration  apache2  symlink 
— Tim
fonte

Risposte:

126

Verifica che Apache disponga dei diritti di esecuzione per /root, /root/sitee /root/site/about.

Correre:

chmod o+x /root /root/site /root/site/about
— palacsint
fonte
8
Grazie mille ... Non mi rendevo conto che anche le directory principali dovevano essere eseguibili.
— Tim,
39
Beh, non sto dicendo che non funzionerà ma in generale, dare o + x su / root non è una buona idea;)
— Michal Rzemieniecki
11
Michal ha ragione. Ho scoperto che potevo usare gli ACL (su Mac, almeno) :, chmod -R +a "_www allow list,search,readattr" /root /root/site /root/site/aboutche concede quei permessi solo all'app Apache (_www), che è un po 'più sicuro di "altro".
— James S
1
Su Mac OS (10.9.4) il mio ~ / Documents non aveva diritti di esecuzione e avevo un repository git dove avrebbe ospitato i file del mio sito. La concessione di chmod o + x su ~ / Documents ha funzionato! Grazie!
— Ernani Joppert
1
Finalmente ho la risposta! Grazie.
— whoan
21

L'errore 403 può anche essere causato da un file system crittografato, ad esempio un collegamento simbolico a una cartella home crittografata .

Se il tuo collegamento simbolico punta alla cartella crittografata, l'utente apache (ad esempio www-data) non può accedere ai contenuti, anche se i permessi di apache e file / cartella sono impostati correttamente. L'accesso dell'utente www-data può essere testato con tale chiamata:

sudo -u www-data ls -l /var/www/html/<your symlink>/

Ci sono accorgimenti / soluzioni a questo, ad esempio l'aggiunta dell'utente www-data al tuo gruppo privato (espone i dati crittografati all'utente web) o impostando una cartella rsynced non crittografata (probabilmente piuttosto sicura). Io stesso probabilmente sceglierò una soluzione rsync durante lo sviluppo.

/ubuntu/633625/public-folder-in-an-encrypted-home-directory

Uno strumento conveniente per i miei scopi è lsyncd . Ciò mi consente di lavorare direttamente nella mia cartella home crittografata e di poter vedere le modifiche quasi istantaneamente nella pagina web di Apache. La sincronizzazione viene attivata dalle modifiche nel file system, chiamando un rsync. Dato che sto lavorando solo su pagine web e script piuttosto piccoli, la sincronizzazione è molto veloce. Ho deciso di utilizzare un breve ritardo di 1 secondo prima che rsync venga avviato, anche se è possibile impostare un ritardo di 0 secondi .

Installazione di lsyncd (in Ubuntu):

sudo apt-get install lsyncd

Avvio del servizio in background:

lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/
— user3811904
fonte
3
Il sudo -u www-data ...è un ottimo modo per verificare se c'è un problema di autorizzazioni! Nota che l'utente potrebbe essere www-data, apache o qualcos'altro a seconda della tua distribuzione.
— mkasberg
Arghh, finalmente! Stavo già dubitando delle mie capacità più elementari!
— kalabalik
Ho perso ore per questo e alla fine è stata la crittografia!
— myol
15

Ho riscontrato un problema simile che non sono riuscito a risolvere per molto tempo sul mio nuovo server. Oltre alla risposta di palacsint, una buona domanda da porsi è: stai usando Apache 2.4? In Apache 2.4 esiste un meccanismo diverso per impostare i permessi che non funzionano quando vengono eseguiti utilizzando la configurazione di cui sopra, quindi ho utilizzato la soluzione spiegata in questo post del blog .

Fondamentalmente, quello che dovevo fare era convertire il mio file di configurazione da:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    allow from all

</Directory>

per:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Nota come le righe Order and allow sono state sostituite da Richiedi tutto concesso

— RightHandedMonkey
fonte
Tieni presente che i comandi Ordina / Consenti / Nega sono ancora disponibili sulla maggior parte dei computer. Nelle versioni più recenti, è implementato nel access_compatmodulo. Se quel modulo è abilitato, è improbabile che la prima parte funzioni come previsto. Se non è presente, il tentativo di avviare Apache2 dovrebbe fallire con errori.
— Alexis Wilke
Quale configurazione? Il /etc/httpd/conf/httpd.confnon esiste sul mio sistema, ed anche, la directory /etc/httpd/non esiste.
— Aaron Franke,
@AaronFranke Hai installato Apache? Potrebbe essere qui: /etc/apache2/httpd.conf /etc/apache2/apache2.conf /etc/httpd/httpd.conf /etc/httpd/conf/httpd.conf
— RightHandedMonkey
Sì, ho installato Apache e sono su Ubuntu. /etc/apache2/apache2.confesiste per me.
— Aaron Franke,
7

In relazione a questa domanda, ho appena capito perché il mio vhost mi stava dando quel 403.

Avevo testato TUTTE le possibilità su questa domanda e altre senza fortuna. Mi fa quasi impazzire.

Sto configurando un server con distribuzione delle versioni simile a Capistrano attraverso i collegamenti simbolici e quando ho provato ad accedere alla cartella DocRoot (che ora è un collegamento simbolico alla cartella della versione corrente) mi ha dato il 403.

Il mio vhost è:

DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
        AllowOverride All
        Options +FollowSymLinks
        Require all granted
</Directory>

e il mio file httpd.conf principale era (installazione predefinita di Apache 2.4):

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes -FollowSymLinks -Includes
(...)

Si scopre che la definizione principale delle opzioni aveva la precedenza sul mio campo vhosts (per me è contro intuitivo). Quindi l'ho cambiato in:

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes +FollowSymLinks -Includes
(...)

ed Eureka! (nota il segno più prima di FollowSymLinks nel file MAIN httpd.conf. Spero che questo aiuti qualche altra anima perduta.

— mustangp51d
fonte
In Apache 2.4, la tua soluzione invaliderà la configurazione e httpd non si avvierà, poiché non puoi combinare "+" e "-" in una singola riga di opzioni.
— deesto
Sì, è stato così, anche se avevo dichiarato un DocumentRoot "prima" nel file, sovrascriveva la sezione Directory figlio (cosa?)
— rogerdpack
2

C'è un altro modo in cui i collegamenti simbolici possono fallire, come ho scoperto nella mia situazione. Se hai un sistema SELinux come server ei link simbolici puntano a una cartella montata su NFS (altri file system possono produrre sintomi simili), httpdpotresti vedere i contesti sbagliati e rifiutare di servire il contenuto delle cartelle di destinazione.

Nel mio caso il contesto SELinux di /var/www/html(che puoi ottenere con ls -Z) è unconfined_u:object_r:httpd_sys_content_t:s0. I collegamenti simbolici in /var/www/htmlavranno lo stesso contesto, ma il contesto di destinazione, essendo una cartella montata su NFS, lo è system_u:object_r:nfs_t:s0.

La soluzione è aggiungere fscontext=unconfined_u:object_r:httpd_sys_content_t:s0alle mountopzioni (ad esempio # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontextè irrilevante e defcontextviene rifiutato da NFS. Non ho provato contextda solo.

— Urhixidur
fonte
2

Prima disabilita selinux (vim / etc / selinux / config)

vim /etc/httpd/conf/httpd.conf modifica le seguenti righe per i collegamenti simbolici e l'indicizzazione delle directory:

documentroot /var/www/html
<directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
</directory>

Se .htaccess file, allora AllowOverride all

— nsn srinivas
fonte
E se non ho la /etc/httpd/cartella sul mio sistema?
— Aaron Franke
1

Oltre a modificare i permessi come indicato dalle altre risposte, ho dovuto riavviare Apache perché avesse effetto:

sudo service apache2 restart
— tmath
fonte
0

Ancora un altro sottile trabocchetto, nel caso tu abbia bisogno AllowOverride All:

Da qualche parte nel profondo dell'albero fs, un vecchio .htaccessavente

    Options Indexes

invece di

    Options +Indexes

era tutto ciò che serviva per disabilitare con nonchalance il FollowSymLinksset nella configurazione del server e causare un misterioso 403 qui.

— Sz.
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.