"Lien symbolique non autorisé ou cible de lien non accessible" / Apache sur CentOS 6

J'ai une toute nouvelle installation de CentOS 6, qui a un lien symbolique dans la racine du document à mes files de développement:

[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/

Mon httpd.conf a ceci:

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

La cible du lien symbolique a des permissions qui devraient permettre à apache de lire tout ce qu'il veut:

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

J'ai également essayé de désactiver SELinux en changeant /etc/selinux/conf :

 SELINUX=disabled

Pourtant, peu importe ce que je fais, quand quelqu'un essaie d'accéder à ce lien, http://localhost/refresh-app/ , j'obtiens une page d'erreur 403 FORBIDDEN et ceci est écrit dans /var/log/httpd/error_log :

 Symbolic link not allowed or link target not accessible

Pourquoi Apache ne peut-il pas accéder à la cible du lien symbolique?

Trouvé le problème. Apache veut avoir access non seulement au directory que je suis en train de servir, /home/billy/refresh-app/ , mais aussi à tous les directorys au-dessus, à savoir /home/billy/ , /home et / . (Je n'ai aucune idée pourquoi … donner à quelqu'un l'access à un sous-directory ne devrait pas nécessiter de donner des permissions à tout ce qui se trouve au-dessus de ce sous-directory ….)

Je suppose qu'il cherche .htaccess ou quelque chose, ou peut-être * nix étant étrange sur la façon dont il traite les permissions pour le directory transversal.

Cette erreur peut également être provoquée si vous créez un lien vers un dossier crypté.

J'ai eu un problème similaire où j'avais la configuration suivante qui fonctionnait avec Ubuntu 10, mais a cessé de fonctionner avec Ubuntu 14 (Apache 2.4):

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

Le fait de passer à ce problème a permis de résoudre le problème (même si l'user du server Web n'a pas pu accéder directement au lien symbolique)

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

D'après ce que je peux dire, c'est juste le paramètre -SymLinksIfOwnerMatch et a quelque chose à voir avec les changements dans Apache 2.4 mais je n'ai pas essayé de searchr la cause exacte.

Je pensais aussi qu'il pourrait être en bas de ressortingctions openbase_dir en PHP, mais ce n'était pas cela.

Il semble que "FollowSymLinks" est l'option dont vous avez besoin dans httpd.conf. C'est détaillé ici . On dirait que vous pourriez avoir besoin d'une règle dans htdocs aussi … mais c'est l'option dont vous avez besoin.

Vous pouvez également vérifier si selinux est appliqué ou non. Sur RedHat / Fedora, exécutez ceci:

 getenforce

Si la réponse est 'Enforcing', vous souhaiterez peut-être exécuter

 setenforce 0

et essayez à nouveau l'URL dans votre browser.

Notez que je ne dis pas que désactiver selinux est la meilleure façon de résoudre ce problème, mais cela peut aider à identifier la cause.

 Options +FollowSymLinks

Créer un file. Htaccess avec cela a fait l'affaire pour moi (mettez-le dans un directory avant le lien symbolique).

que quoi résoudre mon problème après avoir autorisé toutes les permissions et permettre followymlink "Dans le cas de FollowSymLinks spécifiquement, il DOIT être à l'intérieur d'une structure de directory dans un file .conf.

Les options FollowSymLinks et SymLinksIfOwnerMatch ne fonctionnent que dans les sections ou les files .htaccess.

réponse d'ici

Vous pouvez également ajuster vos parameters SELinux, et setenforce peut ne pas être sur votre path. Alors essayez ceci:

 sudo /usr/sbin/setenforce 0

et pour que cela persiste entre les redémarrages

 sudo vi /etc/sysconfig/selinux