Bug #1478


$PHYSICAL["existing-path"] problematic on permissions

Added by class101 almost 13 years ago. Updated almost 12 years ago.

Target version:


Bug found in the last SVN 1.5.0 r-2026


It appear the path specified with $PHYSICALexisting-path is checked by the user/group under wich is loaded the lighttpd, this is problematic when using php read as CGI like this for example:

$PHYSICALexisting-path =~ "\.php$" {

Usualy in CGI mode, you are setting the php files to another user than the http webserver and you chmod 400, this ensure they can only be read by the user designed in spawn-fcgi, but because $PHYSICALexisting-path is checked under the http server user/group it cannot determinate correctly if the path is existing and it spawns lots of

is condition r12 (global/PHYSICALexisting-path=~\.php$) already valid ? nej

within the logs. I have checked by running the http server under the same user/group of the php files, it works, I have no workaround yet and will wait for a new version because I do not want to change all my security on user and group just for a bugging option.



Updated by class101 almost 13 years ago

for unknown reason today I switched to a /chroot configuration and it fixed that behaviour


Updated by class101 almost 13 years ago

Replying to class101:

for unknown reason today I switched to a /chroot configuration and it fixed that behaviour

Ha no sorry not fixed , still getting a 403 denied if I use existing-path, using HTTPurl fixe the prob but it also grap nonexisting php requests.


Updated by Anonymous almost 13 years ago

anyone has a workaround ? Please does 2 days Im searching but cant have existing-path working the way it should, I must set my php files owned by a different user than the one running the lighttpd server but it will return a denied if Im using PHYSICALexisting-path because its doesnt check under the spawn-fcgi user but under the http server .. If I use then HTTPurl =~ "\.php$" it works fine to read the php file under the different user but then any requested endend by .php is processed even if it doesnt exist and I get the PHP5 error "Not input file specified" instead of the standard 404 error because of the missing local check before to process the unknown .php request. that bug is very boring, please fixe!!! PHYSICALexisting-path SHOULD be checked under the user running the PHP files (the spawn-fcgi user) and not the user under wich is running lighttpd.........................


Updated by Anonymous almost 13 years ago

ok i've found a temp solutioon with is to put both users in same group and playing with group permissions , for me that sound fast , compliant ok , but not secure ... critical bug.


Updated by stbuehler over 12 years ago

How could lighttpd check if the file exists, if you don't give it the permission?

lighttpd runs as normal user and cannot switch to another user to check if a file exists.

If you want only lighttpd and the normal user to see the files, you could as root setup a folder with "webuser:www-data rwxr-x---" permissions; webuser doesn't have to be in the www-data group.
(assuming www-data is the group of lighttpd).

To see the files (and check if they exist), lighty should only need the execute right for the directories (and their parent directories up to /), it does not need to be able to read the files.


Updated by Anonymous over 12 years ago

yep I changed my configuration to only use the group + owner permission rather than the owner + user permissions, this was surprising me first moving from apache because that is a bit different I was able to use the owner + user permission without groups however I prefer know how it it is owner + group without without user permissions, a bit more secured.


Updated by stbuehler over 12 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid

Either you want lighty to check if the file exists, then it needs the permission to do so.

Or use "path" instead of "existing-path", if you only want to match the filename without checking it .


Updated by stbuehler almost 12 years ago

  • Status changed from Fixed to Invalid

Also available in: Atom