Results 1 to 8 of 8

Thread: Slackware: 403 errors with PHP files under lighttpd

  1. #1
    Join Date
    Sep 2006
    Posts
    16

    Default Slackware: 403 errors with PHP files under lighttpd

    It took a damn long six hours, but i've configured Slackware, smacked PHP (with FastCGI) on (the hours were spent looking for lib after lib after... that's the part about Linux/NIX in general that i hate - looking for dependancies) and got it under lighttpd - but everytime i go to access a PHP file on my site, all i get is a 403 error.

    Sorry to have to ask for help for the millionth time in a few days, but can anyone help out?

  2. #2
    Join Date
    Aug 2006
    Posts
    1,019

    Default

    Well, a 403 error is a forbidden error. Do you have permissions set correctly?

  3. #3
    Join Date
    Sep 2006
    Posts
    16

    Default

    Quote Originally Posted by jasonaward
    Well, a 403 error is a forbidden error. Do you have permissions set correctly?
    As far as i'm aware. I CHMODed the test.php file to 777 just in case.

    The only other thought that crossed my mind is perhaps PHP itself or lighttpd need CHOWNing?

  4. #4
    Join Date
    Jun 2006
    Location
    Guadalajara, Mexico
    Posts
    541

    Default

    you can check what user/group its being used by the webserver at 'lighttpd.conf'
    pablasso.com (spanish)

  5. #5
    Join Date
    Jun 2006
    Location
    Sydney, Australia
    Posts
    97

    Default

    Quote Originally Posted by testpie
    The only other thought that crossed my mind is perhaps PHP itself or lighttpd need CHOWNing?
    PHP via FastCGI should run with the same user/group as lighttpd if they spawn off from lighttpd.

    You might want to check the error log (/var/log/lighttpd/error.log) to see what caused permission error. Or try to see whether the full path is accessible, for example

    Code:
    # sudo -u lighttpd cat /var/www/localhost/htdocs/full_path_to/my_file.php > /dev/null
    check whether there's an error message.

  6. #6
    Join Date
    Sep 2006
    Posts
    16

    Default

    Quote Originally Posted by scotty
    PHP via FastCGI should run with the same user/group as lighttpd if they spawn off from lighttpd.
    I've just reassigned lighttpd to the user "lighttpd" with usergroup "lighttpd", and lighttpd seems to come up. When i use the "top" command, both lighttpd and php-cgi are running under the user "lighttpd" - so this seems fine.

    Quote Originally Posted by scotty
    You might want to check the error log (/var/log/lighttpd/error.log) to see what caused permission error. Or try to see whether the full path is accessible, for example

    Code:
    # sudo -u lighttpd cat /var/www/localhost/htdocs/full_path_to/my_file.php > /dev/null
    check whether there's an error message.
    There's no errors in the error file, and i've CHOWNed the /var/www/lighttpd directory to "lighttpd", run the above sudo commonad and so on. However, i'm still getting the "Error 403: Permission denied" problem - have you got any other thoughts?

    Thanks for your help so far.

  7. #7
    Join Date
    Sep 2006
    Posts
    16

    Default

    I think i've figured it out, but am afraid it might cause some kind of security error. Basically, in lighttpd.conf there was this section:
    Code:
    ## deny access the file-extensions
    #
    # ~    is for backupfiles from vi, emacs, joe, ...
    # .inc is often used for code includes which should in general not be part
    #      of the document-root
    # .php extension is disabled by default for security reasons (Toni Spets)
    url.access-deny             = ( "~", ".inc", ".php" )
    I've removed the ".php" part from here and it seems to work fine. Can someone please explain why this is even in here? I am running lighty and PHP insecurely by removing the ".php" extension from url.access-deny?

    If not, why the hell is that line even there?

  8. #8
    Join Date
    Aug 2006
    Posts
    1,019

    Default

    Well, my assumption is that it was disabled by default for security reasons.

    They probably wanted to prevent people from inadvertently allowing PHP scripts to run on their server and by denying it by default, it makes you (the admin) enable it. Further, if you had php files on your server, but didn't have the PHP interpreter installed, it would actually show you the PHP source (definitely a bad security hole) instead of interpreting it.

    So, being that you set up PHP properly, and you intentionally want PHP files to be interpreted, you're okay. Good job finding the error!

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •