Come posso risolvere un errore di PHP "Avviamento non riuscito" in un context di symlink?

Sto eseguendo Apache / PHP su MacOS X Lion 10.7.4. La struttura della mia directory è impostata come segue:

/Users/achan/Sites/ lrwxrwx--- 1 achan staff 23B Apr 27 16:21 epwbst@ -> /Users/achan/dev/epwbst` 

where epwbst/ è un epwbst/ all'interno di ~/Sites .

Se metto test.php all'interno della directory Sites/ directory, Apache serve correttamente il file; espande phpinfo() come si suppone. Se metto lo stesso file sotto il simbolo, ottengo questo errore:

 [Mon May 28 14:47:13 2012] [error] [client ::1] PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 [Mon May 28 14:47:13 2012] [error] [client ::1] PHP Fatal error: Unknown: Failed opening required '/Users/achan/Sites/epwbst/test.php' (include_path='.:/usr/lib/php/pear') in Unknown on line 0 

Solo per essere sicuro che Apache stava lavorando, ho creato un file html di prova in ~/Sites/epwbst/ e Apache lo ha servito come previsto.

Perché Apache non può eseguire php sotto la mia directory di symlinked?

Ho incollato la mia configuration di php qui: http://pastebin.com/gg27JyVZ

  • Stampa PDF - printing 50Mb da file PDF da 1Mb.
  • Come effettivamente eseguire less processi php-cgi?
  • Utilizzo di lince o wget in cron per call uno script php?
  • PHP mangia molto memory su IIS
  • L'impostazione dell'intestazione di In rende la posta () richiede molto tempo per submit
  • phpmyadmin che ha problemi su nginx e php-fpm su RHEL 6
  • Apache .htaccess <ifModule non consentito qui
  • Installazione sicura di Wordpress in una sottodirectory su un server
  • One Solution collect form web for “Come posso risolvere un errore di PHP "Avviamento non riuscito" in un context di symlink?”

    Ok, questo mi ha guidato per ore . È un problema di autorizzazioni, ma non come si potrebbe pensare. Il problema è il permesso del collegamento simbolico stesso:

     /Users/achan/Sites/ lrwxrwx--- 1 achan staff23B Apr 27 16:21 epwbst@ -> /Users/achan/dev/epwbst` 

    Ecco il rub: chmod normalmente non cambia le autorizzazioni sui collegamenti simbolici perché (con l'exception apparente di php5_module e altri casi oltre l'ambito di questa risposta) tali autorizzazioni sono in gran parte irrilevanti poiché vengono ignorate in quasi tutti i contesti. Ecco la correzione:

     chmod -h 755 /Users/achan/Sites/epwbst 

    Si noti il -h . Dalla pagina uomo:

     ... -h If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to. ... 

    Per qualche motivo, php5_module prende attenzione alle autorizzazioni del collegamento simbolico. Se sono troppo restrittivi, php5_module rifiuterà di visualizzare l'objective, anche se l'utente di httpd potrebbe altrimenti leggere e eseguire lo stesso target utilizzando /usr/bin/php .

    Si consideri quanto segue:

     % umask 027 % cd ~/Sites % mkdir bar % chmod 755 bar % ln -sv bar foo foo -> bar % ls -al ~/Sites/foo lrwxr-x--- 1 xyz xyz 3 Apr 22 13:17 foo -> bar % ls -adl ~/Sites/foo/. drwxr-xr-x 2 xyz xyz 68 Apr 22 13:17 /Users/xyz/Sites/foo/. % echo 'Hello!' >bar/hello.txt % chmod 644 bar/hello.txt % curl http://localhost/~xyz/bar/hello.txt Hello! % curl http://localhost/~xyz/foo/hello.txt Hello! 

    Fin qui tutto bene. Ora considerate:

     % echo '<?php phpinfo(); ?>' >bar/info.php % chmod 644 bar/info.php % curl http://localhost/~xyz/bar/info.php <html xmlns="http://www.w3.org/1999/xhtml"><head> ... </div></body></html> % curl http://localhost/~xyz/foo/info.php <br /> <b>Warning</b>: Unknown: failed to open stream: No such file or directory in <b>Unknown</b> on line <b>0</b><br /> <br /> <b>Fatal error</b>: Unknown: Failed opening required '/Users/xyz/Sites/foo/info.php' (include_path='.:') in <b>Unknown</b> on line <b>0</b><br /> 

    Hmmm. Il mio httpd viene eseguito come utente _www , quindi controlliamo per vedere se l'utente può leggere .../foo/info.php :

     % sudo sudo -u _www cat ~/Sites/foo/info.php Password: <?php phpinfo(); ?> 

    Sì. Ora vediamo se quell'utente può eseguire .../foo/info.php :

     % sudo sudo -u _www /usr/bin/php ~/Sites/foo/info.php Password: phpinfo() PHP Version => 5.4.24 ... If you did not receive a copy of the PHP license, or have any questions about PHP licensing, please contact license@php.net. 

    Sì?! WTF ?! Grrr! Ora ripari:

     % chmod -h 755 foo % curl http://localhost/~xyz/foo/info.php <html xmlns="http://www.w3.org/1999/xhtml"><head> ... </div></body></html> 

    Scoppio. Fatto.

    Quindi sì. Sembra che php5_module fa qualcosa di paranoico e non standard. Questo può essere trascurato visto che l' umask spesso è impostato su 022 , che crea alless collegamenti simbolici con 755 . Inoltre, molti filesystem (non HFS +) impongono alle autorizzazioni di livello del kernel di 777 durante la creazione di collegamento simbolico, indipendentemente da umask .

    Lei e io sembriamo essere le due persone del sistema solare che eseguono Apache + PHP su HFS +, impostando l'umask su qualcosa di più restrittivo del default. Scommetto che utilizzi anche HFS + per i casi sensibili. ; O)

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.