"Link simbolico non consentito o link target non accessibile" / Apache su CentOS 6


30

Ho una nuovissima installazione di CentOS 6, che ha un link simbolico nella radice del documento ai miei file di sviluppo:

[root@localhost html]# ls -l
total 4
-rwxrwxrwx. 1 root root  0 Sep 18 20:16 index.html
-rwxrwxrwx. 1 root root 17 Sep 18 20:16 index.php
lrwxrwxrwx. 1 root root 24 Sep 18 20:19 refresh-app -> /home/billy/refresh-app/

Il mio httpd.conf ha questo:

<Directory "/">
    Options All
    AllowOverride None
    Order allow,deny
    Allow from all
</directory>

La destinazione del collegamento simbolico ha autorizzazioni che dovrebbero consentire ad apache di leggere tutto ciò che vuole:

 [root@localhost billy]# ls -l
total 40 (Some entries were omitted because the list was too long
drwxr-xr-x. 7 billy billy 4096 Sep 18 20:03 refresh-app

Ho anche provato a disabilitare SELinux modificando /etc/selinux/conf:

SELINUX=disabled

Eppure, qualunque cosa io faccia, quando qualcuno tenta di http://localhost/refresh-app/accedere a quel link, ricevo una pagina di errore 403 FORBIDDEN e questo è scritto nel /var/log/httpd/error_log:

Symbolic link not allowed or link target not accessible

Perché Apache non può accedere alla destinazione del collegamento simbolico?


Quale utente esegue Apache? Riesci davvero a leggere quella risorsa come quell'utente?
draeath

Inoltre, è meglio eseguire selinux in modalità permissiva e quindi utilizzare sealert per analizzare il registro di controllo - questo ti consente di vedere perché / come SELinux lo sta negando e spesso ti dà anche una risoluzione.
draeath

@draeath: non ho idea di come verificarlo.
Billy ONeal,

@draeath: 1. Questa non è una scatola di produzione; Non mi interessa se SELinux è spento. 2. In ogni caso, sto solo risolvendo i problemi a questo punto - probabilmente lo ripristinerò dopo aver scoperto la causa principale.
Billy ONeal,

Non preoccuparti, questa è una svista comune, la prima volta che l'ho fatto sono rimasto bloccato per giorni, serverfault.com/questions/313485/… :: È uno di quegli errori. : D
whoami,

Risposte:


44

Trovato il problema. Risulta, Apache vuole accedere non solo alla directory che sto servendo, /home/billy/refresh-app/ma anche ogni directory superiore a quella, cioè /home/billy/, /homee /. (Non ho idea del perché ... dare a qualcuno l'accesso a una sottodirectory non dovrebbe richiedere la concessione di autorizzazioni a tutto ciò che si trova sopra quella sottodirectory ....)

Immagino che .htaccessstia cercando o qualcosa del genere, o forse * nix è strano su come tratta le autorizzazioni per la directory trasversale.


15
Non è strano Funziona così. Devi avere + x per l'intero percorso a cui stai tentando di accedere.
bahamat,

4
@bahamat: non ha alcun senso. Perché qualcuno dovrebbe avere i privilegi di esecuzione per i file che non vengono eseguiti? (Questo attualizzazione totale del fatto che non si dovrebbe dare via i diritti a /... praticamente mai) I sistemi con ACL di solito hanno un'opzione trasversale indiretta separata. Penseresti che dopo 30 anni dalla progettazione di Unix e dalla vasta disponibilità di sistemi ACL, gli ACL sarebbero lo standard. : sospiro:
Billy ONeal,

11
Credo che volesse dire + x nelle directory. Prova a passare all'utente e inserire il cd nella directory w / o + x. Dalla memoria + x ti permette di accedere ma non vedere la directory mentre + r ti permette di elencare i file e + w ti permette di cambiare i file in detta directory

1
@BillyONeal: la frase "percorso intero" implica directory.
bahamat,

5
Questo è un comportamento corretto in unix. È necessario eseguire i privilegi (+ x per go) sulle directory principali che si sta tentando di modificare in sottodirectory sotto di esse.
slm

11

Ho avuto un problema simile in cui avevo la seguente configurazione che funzionava con Ubuntu 10, ma ha smesso di funzionare con Ubuntu 14 (Apache 2.4):

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +FollowSymLinks
</Directory>

Passando a questo, il problema è stato risolto (anche se l'utente del web server non è stato in grado di accedere direttamente al collegamento simbolico)

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>

Da quello che posso dire è solo l' -SymLinksIfOwnerMatchimpostazione e ha qualcosa a che fare con i cambiamenti in Apache 2.4 ma non ho provato a ricercare la causa esatta.

Ho anche pensato che potesse dipendere dalle openbase_dirrestrizioni in PHP, ma non era così.


6

Questo errore può anche essere causato se si collega a una cartella crittografata.


4

Sembra che "FollowSymLinks" sia l'opzione necessaria in httpd.conf. È dettagliato qui . Sembra che potresti aver bisogno di una regola anche in htdocs ... ma è l'opzione che ti serve.


3
Vedi Options All- FollowSymLinksè già specificato.
Billy ONeal,

2

Potresti anche voler verificare se selinux è applicato o meno. Su RedHat / Fedora, eseguire questo:

getenforce

Se la risposta è 'Enforcing', potresti voler eseguire

setenforce 0

e prova di nuovo l'URL nel tuo browser.

Nota che non sto dicendo che disabilitare Selinux sia il modo migliore per risolvere questo problema, ma potrebbe aiutare a identificare la causa.


questo ha risolto il problema del collegamento simbolico ma ci sono effetti negativi?
digz6666,

2
Options +FollowSymLinks

Creare un file .htaccess con questo ha fatto il trucco per me (mettilo in una directory prima del collegamento simbolico).


Nel mio caso, stavo creando /var/wwwun collegamento simbolico con un altro collegamento simbolico intermedio. Se è necessario utilizzare collegamenti simbolici, renderlo un collegamento simbolico DIRETTAMENTE alla destinazione.
Sridhar Sarnobat,

0

che ciò che risolve il mio problema dopo consenti tutte le autorizzazioni e consenti followymlink "Nel caso specifico di FollowSymLinks DEVE trovarsi all'interno di una struttura Directory all'interno di un file .conf. Dal manuale attuale di Apache

Le opzioni FollowSymLinks e SymLinksIfOwnerMatch funzionano solo in sezioni o file .htaccess.

risposta da qui


0

La mia soluzione era quella di creare una cartella condivisa per tutti i repository denominati /home/repo.

Quindi symlink da casa mia come: ln -s /home/repo ~/Code così ~/Code/www.xxxx.com/public indica /home/repo/www.xxxx.com/public

e anche un collegamento in apache web root /var/www/html punta a /home/repo/www.xxxx.com/public

Trovato qui: https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide

Con alcuni symlink + gruppi di utenti di acrobazia è possibile distribuire più utenti / versioni.


0

@Billey ONeil @Flion Non ho potuto rispondere in linea (basso numero di ripetizioni)
Ecco cosa dovevo fare:
( nota: alias ll = 'ls $ LS_OPTIONS -lh')

root@Bellach:/var/www/html# ll lego
lrwxrwxrwx 1 root root 43 Sep 10 21:21 lego -> /home/DATA/Documents/Chris/Synced/web/lego/

Ora guarda tutte le directory nel link sorgente

root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/web/
drwxr-xr-x 9 chris chris 4.0K Sep 12  2017 /home/DATA/Documents/Chris/Synced/web/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/
drwxr-xr-x 20 chris chris 4.0K Mar 27 18:52 /home/DATA/Documents/Chris/Synced/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/
drwxr-xr-x 36 chris chris 4.0K Jun 17 23:31 /home/DATA/Documents/Chris/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/
drwxr-xr-x 21 chris chris 4.0K Aug  7 18:22 /home/DATA/Documents/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-- 10 root users 4.0K Sep 10 11:17 /home/DATA/
root@Bellach:/var/www/html# ll -d /home/
drwxr-xr-x 5 root root 4.0K Sep 10 10:37 /home/

La directory / home / DATA è il colpevole.
Risolvilo con questo:

root@Bellach:/var/www/html# chmod +x /home/DATA/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-x 10 root users 4.0K Sep 10 11:17 /home/DATA/

La correzione è immediata: non è necessario riavviare apache.


-1

Potresti anche regolare le tue impostazioni SELinux e setenforce potrebbe non essere sul tuo percorso. Quindi prova questo:

sudo /usr/sbin/setenforce 0

e per rendere questo persistere tra i riavvii

sudo vi /etc/sysconfig/selinux
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.