FAQ
Hello. I'm not sure if this is an apache problem or php... but
wondering if anyone has come across the same problem.

-rw------- 1 root root test.html
-rw------- 1 root root test.php

Trying to access test.html via a browser servers up the apache 403 error
page. The test.php however produces:

Warning: Unknown: failed to open stream: Permission denied in Unknown on
line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
(include_path='.:/www/php') in Unknown on line 0

Any ideas?

Thanks!

--
Jason Morehouse
Vendorama - Create your own online store
http://www.vendorama.com

Search Discussions

  • Brad Pauly at Jan 10, 2005 at 7:51 pm

    On Mon, 10 Jan 2005 13:49:26 -0500, Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown on
    line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
    (include_path='.:/www/php') in Unknown on line 0

    Any ideas?
    It's a permissions problem. Both of those files are owned by the root
    user and I would guess that apache is not running as root (and it
    shouldn't be!). Find out who apache is running as (commonly www or
    nobody) and give that user access to those files.

    Brad
  • Trobi at Jan 10, 2005 at 7:54 pm

    Jason Morehouse wrote / napísal (a):

    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403
    error page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown
    on line 0 Warning: Unknown: Failed opening '/www/test.php' for
    inclusion (include_path='.:/www/php') in Unknown on line 0

    Any ideas?

    Thanks!
    What about:
    as root:
    chmod 775 test.php
    then
    chmod 775 test.html

    Theese comands gives the right to read and execute to web server runing
    with nobody rights
    to read and execute above mentioned files.

    trobi
  • Curt Zirzow at Jan 10, 2005 at 9:57 pm

    * Thus wrote trobi:
    Jason Morehouse wrote / napísal (a):
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php
    What about:
    as root:
    chmod 775 test.php
    then
    chmod 775 test.html
    chmod 644 is more appropriate.

    Curt
    --
    Quoth the Raven, "Nevermore."
  • Richard Lynch at Jan 10, 2005 at 8:03 pm

    Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown on
    line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
    (include_path='.:/www/php') in Unknown on line 0

    Any ideas?
    Apache (and the PHP Module within it) run as a specific user.

    That user is not (and SHOULD NOT be) 'root'

    You need to figure out what user Apache runs as.

    It's set in httpd.conf by the 'User' directive.

    Because Apache/PHP does not run as 'root', Apache/PHP do not have
    permission to *READ* the file.

    If they can't *READ* the file, they can't deliver it to the surfer.

    You need to change the permissions on the file to be *READABLE* by the
    'User' of Apache/PHP.

    Example
    chmod 644 test.html
    chmod 644 test.php

    However, it would probably be even *better* to chown the files to some
    less-powerful user than 'root'

    chown _SOME_USER_ test.html
    chown _SOME_USER_ test.php

    You'll *still* need them to be read-able by Apache/PHP -- But in the
    unlikely event that somebody Evil manages to gain write-access to the
    files, at least they won't be root-owned, which would be even *worse* than
    just a normal user's files getting hacked.

    You really need to read a tutorial on Unix file permsissions, and you have
    *GOT* to stop making HTML and PHP files as 'root' user!

    Danger Will Robinson Danger!
  • Jason Morehouse at Jan 10, 2005 at 8:13 pm

    Richard Lynch wrote:
    Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown on
    line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
    (include_path='.:/www/php') in Unknown on line 0

    Any ideas?

    Apache (and the PHP Module within it) run as a specific user.

    That user is not (and SHOULD NOT be) 'root'

    You need to figure out what user Apache runs as.

    It's set in httpd.conf by the 'User' directive.

    Because Apache/PHP does not run as 'root', Apache/PHP do not have
    permission to *READ* the file.

    If they can't *READ* the file, they can't deliver it to the surfer.

    You need to change the permissions on the file to be *READABLE* by the
    'User' of Apache/PHP.

    Example
    chmod 644 test.html
    chmod 644 test.php

    However, it would probably be even *better* to chown the files to some
    less-powerful user than 'root'

    chown _SOME_USER_ test.html
    chown _SOME_USER_ test.php

    You'll *still* need them to be read-able by Apache/PHP -- But in the
    unlikely event that somebody Evil manages to gain write-access to the
    files, at least they won't be root-owned, which would be even *worse* than
    just a normal user's files getting hacked.

    You really need to read a tutorial on Unix file permsissions, and you have
    *GOT* to stop making HTML and PHP files as 'root' user!
    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.

    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.


    --
    Jason Morehouse
    Vendorama - Create your own online store
    http://www.vendorama.com
  • Curt Zirzow at Jan 10, 2005 at 10:04 pm

    * Thus wrote Jason Morehouse:
    Richard Lynch wrote:
    Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:
    ...
    Apache (and the PHP Module within it) run as a specific user.

    That user is not (and SHOULD NOT be) 'root'
    ...
    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.
    Your Original Post did not state that you knew why the error
    occured, we can't reminds after all.
    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    It is recommended *not* to have 'display_errors=on' for a production
    server for this very reason. Have the errors go to syslog or
    something similar.

    Curt
    --
    Quoth the Raven, "Nevermore."
  • SED at Jan 11, 2005 at 12:25 am
    Hi,

    Sometimes when I write a PHP-script and upload it to a ISP through password
    protected FTP, the only way to write data to a folder is to run chmod 777
    for that folder, I want to write (or save) a data to (e.g. file-upload,
    flat-file-database). However, if I do so, I have been told, everyone can
    write data to that file, which is a security risk. Is that true?

    If I do so, is it right that anyone can write a data to that folder? E.g.
    PHP-script that can reveal everything?

    Regards,
    SED
  • Curt Zirzow at Jan 11, 2005 at 4:36 am

    * Thus wrote SED:
    Hi,

    Sometimes when I write a PHP-script and upload it to a ISP through password
    protected FTP, the only way to write data to a folder is to run chmod 777
    for that folder, I want to write (or save) a data to (e.g. file-upload,
    flat-file-database). However, if I do so, I have been told, everyone can
    write data to that file, which is a security risk. Is that true?
    yes, chmod'ing a directory to 777 is not the wisest thing to do.

    If security is a major concern you can lock down you directory you
    wish to have your files stored in on a shared server with some
    context like:

    Assuming you have your files stored in:

    /www/domain.com/htaccess ; the docroot
    /www/domain.com/special ; locked down files
    /www/domain.com/ ; your ftp root

    via ftp make a directory:
    /www/domain.com/special/store/

    chmod 777 /special/store

    Then make a php script that does something like:

    mkdir('/www/domain.com/special/store/files/');
    chmod('/www/domain.com/special/store/files', 0700);

    execute the script with the browser.


    Now back in ftp:
    chmod 755 /special/store


    And wala.. your /www/domain.com/special/store/files is secure as
    long as open_basedir is in effect.


    HTH,


    Curt
    --
    Quoth the Raven, "Nevermore."
  • Richard Lynch at Jan 11, 2005 at 7:25 pm

    SED wrote:
    Sometimes when I write a PHP-script and upload it to a ISP through
    password
    protected FTP, the only way to write data to a folder is to run chmod 777
    for that folder, I want to write (or save) a data to (e.g. file-upload,
    flat-file-database). However, if I do so, I have been told, everyone can
    write data to that file, which is a security risk. Is that true?

    If I do so, is it right that anyone can write a data to that folder? E.g.
    PHP-script that can reveal everything?
    If it's 777, they don't even need to write a PHP script to read/write it.

    ANYBODY with a login on the same server, or anybody who manages to break
    into that server, will be able to read/write this file.

    One common practice is to chown/chmod the files that PHP needs to
    read/write so only the PHP user can read/write them. If the PHP user (see
    output of http://php.net/phpinfo) can read/write the files, but nobody
    else can, you've raised the bar a little bit to access.

    This then limits the access to PHP scripts.

    Of course, some other user with a login can write a PHP script, load it in
    their browser, and effectively be running as the PHP user and still
    read/write your data, same as you.

    If you think about this a bit, you'll realize that you've got a chicken
    and egg problem: If *your* PHP script can alter the data, so can theirs.
    If you make it so *their* PHP script can't alter the data, neither can
    yours, and your application won't be real useful, eh?

    [+} It was rumored at some point that Apache 2 would allow PHP Modules to
    be run as different users in different VirtualHosts. A recent post by
    Rasmus makes me think that never happened. But maybe it did. RTFM. If
    you *can* set up your server that way, and make each VirtualHost run PHP
    Module as a different user, then you can limit access in Apache 2 in a
    better way.

    You can add a *tiny* bit of a barrier by burying the stuff PHP can
    read/write *outside* the web tree, and only display things on your server
    using PHP to 'filter' the content.

    For example, if you allow JPEGs to be uploaded, set up your PHP
    readable/writeable directory in, say, ~/image instead of
    ~/public_html/images

    Then you need a PHP script to 'display' the JPEG:
    <?php
    /* display.php */
    if (!isset($_SERVER['PATH_INFO'])){
    trigger_error("Invalid attempt to use display.php without specifying
    image filename, possibly for nefarious reasons.", E_USER_ERROR);
    exit;
    }
    $filename = $_SERVER['PATH_INFO'];
    $filename = preg_replace('/[A-Za-z0-9_\\.-]/', '', $filename);
    if ($filename != $_SERVER['PATH_INFO']){
    trigger_error("Invalid character in image filename, possibly for
    nefarious reasons.", E_USER_ERROR);
    exit;
    }
    readfile("/full/path/to/your/home/images/$filenaem");
    ?>

    You can even bury it *inside* a directory that the PHP user can *NOT*
    read, so the Bad Guy has to "guess" at the name of the directory that they
    can read, because it's inside a directory that they can't read:

    mkdir access
    chmod 600 access
    mkdir access/images
    chmod 700 access/images
    chown apache access/images

    So now the 'apache' user (may be 'nobody' or 'www' or ... on your system)
    can do what it wants with the images directory, but somebody poking around
    in your system won't *KNOW* there is an images directory, cuz they can't
    read 'access' directory to find out it's there.

    You then change the PHP display.php script to run some basic sanity checks
    before presenting any JPEG to the browser.

    You can, fairly easily:

    Be sure that http://php.net/getimagesize 'works' on the JPEG, so it's
    probably a JPEG and not some kind of Trojan/Virus/Whatever.

    Only serve up images that were recorded through your application in the
    database as having been uploaded. So if somebody manages to put a JPEG in
    your directory, they'd *also* have to hack into your MySQL data to add it
    to the database.

    Record an http://php.net/md5 hash of the file when it was uploaded, so if
    somebody changes the file out from under you, you can do md5() again and
    see that it was changed.

    If all these security measures are insufficient for your application, then
    it's time to buy a dedicated server, where there aren't any other PHP
    users other than yourself [*] and then this is all moot.

    [*] Of course, on a dedicated server, if a hacker breaks in, they can
    probably run PHP and do these "Bad Things" but if they've already broken
    in, you've got MUCH BIGGER PROBLEMS than your PHP-alterable data.

    For *MOST* web applications, the measures outline here (or similar) are
    sufficient, so you can make PHP "secure enough" to manage your risk to an
    acceptable level on a shared server.

    In some cases, you simply can't, and you need a dedicated server -- But
    that's usually something you know you need anyway, for all the *OTHER*
    security issues involved in the first place.

    PS The ideas above are but a fraction of the kinds of things one can do to
    limit access and sanity check content using PHP.
  • Jason Wong at Jan 10, 2005 at 10:08 pm

    On Tuesday 11 January 2005 04:13, Jason Morehouse wrote:

    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.
    Maybe you should have made more explicit in your original post what your
    question was (as is evident in the number of inappropriate responses that you
    have received).
    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions.
    Well it will display said error message IFF you have display_errors enabled.
    On a production machine display_errors should *not* be enabled.
    Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    No idea.

    --
    Jason Wong -> Gremlins Associates -> www.gremlins.biz
    Open Source Software Systems Integrators
    * Web Design & Hosting * Internet & Intranet Applications Development *
    ------------------------------------------
    Search the list archives before you post
    http://marc.theaimsgroup.com/?l=php-general
    ------------------------------------------
    New Year Resolution: Ignore top posted posts
  • Jason Wong at Jan 10, 2005 at 8:11 pm

    On Tuesday 11 January 2005 02:49, Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.
    It's a file permissions problem as can be seen clearly below (which you've
    thoughtfully included).
    -rw------- 1 root root test.html
    -rw------- 1 root root test.php
    Only root can access those files. Unless you're running apache as root
    (hopefully you're not) then apache won't be able to read those files and
    hence ...
    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown on
    line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
    (include_path='.:/www/php') in Unknown on line 0
    Any ideas?
    Change the ownership of those files to that of the user running apache or make
    them readable by others (chmod o+r).

    --
    Jason Wong -> Gremlins Associates -> www.gremlins.biz
    Open Source Software Systems Integrators
    * Web Design & Hosting * Internet & Intranet Applications Development *
    ------------------------------------------
    Search the list archives before you post
    http://marc.theaimsgroup.com/?l=php-general
    ------------------------------------------
    New Year Resolution: Ignore top posted posts
  • Travis Conway at Jan 10, 2005 at 9:05 pm
    you have to allow others to read it.

    You have it so only root can access the file. Try this:

    chmod 644 test.php

    while logged in as root. This should put the file as

    -rw-r--r-- 1 root root test.php

    HTH

    Travis
    ----- Original Message -----
    From: "Jason Morehouse" <jm@vendorama.com>
    To: <php-general@lists.php.net>
    Sent: Monday, January 10, 2005 12:49 PM
    Subject: [PHP] 403 not working -- apache 2 / php5 / linux

    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403 error
    page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown on
    line 0 Warning: Unknown: Failed opening '/www/test.php' for inclusion
    (include_path='.:/www/php') in Unknown on line 0

    Any ideas?

    Thanks!

    --
    Jason Morehouse
    Vendorama - Create your own online store
    http://www.vendorama.com

    --
    PHP General Mailing List (http://www.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jonel Rienton at Jan 10, 2005 at 9:14 pm
    man chmod, i gather you're new to linux/*nix

    http://jonel.road14.com
    --
    I not know English well, but I know 7 computer languages.
    ----anonymous

    On Jan 10, 2005, at 12:49 PM, Jason Morehouse wrote:

    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403
    error page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown
    on line 0 Warning: Unknown: Failed opening '/www/test.php' for
    inclusion (include_path='.:/www/php') in Unknown on line 0

    Any ideas?

    Thanks!

    --
    Jason Morehouse
    Vendorama - Create your own online store
    http://www.vendorama.com

    --
    PHP General Mailing List (http://www.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jason Morehouse at Jan 10, 2005 at 9:21 pm

    Jonel Rienton wrote:
    man chmod, i gather you're new to linux/*nix
    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.

    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.



    --
    Jason Morehouse
    Vendorama - Create your own online store
    http://www.vendorama.com
  • Jason Barnett at Jan 10, 2005 at 9:47 pm

    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    Yeah, this is really better on an Apache list... but...
    http://httpd.apache.org/docs/mod/core.html#errordocument


    --
    Teach a person to fish...

    Ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html
    PHP Manual: http://php.net/manual/
    php-general archives: http://marc.theaimsgroup.com/?l=php-general&w=2
  • Rasmus Lerdorf at Jan 11, 2005 at 12:25 am

    Jason Barnett wrote:
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    Yeah, this is really better on an Apache list... but...
    http://httpd.apache.org/docs/mod/core.html#errordocument
    No, it has nothing to do with Apache. Apache doesn't open the file, PHP
    does. You could argue that PHP should try to throw a 403 on a
    permissions error, but the problem is that it is really too late in the
    game to do so once we get to the content handler phase where PHP lives.
    It could be hacked to do it a number of ways, but it wouldn't be pretty
    and it wouldn't be very consistent either since we would have to only do
    it if no output has been sent on the request yet. So a sub-request or
    an auto-prepend would both change the behaviour.

    Turning off display_errors really is the answer to the particular
    security concern raised here.

    -Rasmus
  • Richard Lynch at Jan 11, 2005 at 6:59 pm

    Rasmus Lerdorf wrote:
    Jason Barnett wrote:
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    Yeah, this is really better on an Apache list... but...
    http://httpd.apache.org/docs/mod/core.html#errordocument
    No, it has nothing to do with Apache. Apache doesn't open the file, PHP
    does. You could argue that PHP should try to throw a 403 on a
    permissions error, but the problem is that it is really too late in the
    game to do so once we get to the content handler phase where PHP lives.
    It could be hacked to do it a number of ways, but it wouldn't be pretty
    and it wouldn't be very consistent either since we would have to only do
    it if no output has been sent on the request yet. So a sub-request or
    an auto-prepend would both change the behaviour.
    Actually, as the naive PHP programmer, I'd only want it to happen if it
    were "the file matching the original URI request" rather than "no content
    sent to the browser yet"

    Consider:
    <?php
    /* index.php */
    require 'connect.inc';
    require 'authenticate.inc';
    ?>

    If index.php is not readable, then a 403 would make sense to me.

    But suppose index.php is readable, and so is connect.inc, but *not*
    authenticate.inc:

    chmod 644 index.php
    chmod 644 connect.inc
    chmod 000 authenticate.inc

    If authenticate.inc were not readable, a 403 sent because PHP can't read
    one of those files would just be morally wrong, even if no content went to
    the browser yet.

    Because it's real likely that *I* am sending a 403 as part of my script in
    authenticate.inc, using HTTP Basic Authentication as described in the PHP
    manual.

    You'd be confusing the HELL out of me to have PHP sending out a 403
    because it couldn't read the included file after it already managed to
    read index.php and connect.inc

    At that point, the problem is not that the page is not readable, but some
    portion of PHP script is not readable, and I would expect PHP to know the
    difference.

    That may be an unreasonable expectation on my part, and maybe I'm just
    spoiled by PHP's exemplary behaviour in the past of telling me exactly
    which file where I managed to screw up, but that's what I expect from PHP
    these days. :-)

    I suspect that this makes it even more of a hack to try to do, and even
    less likely, if it's even possible to be less likely, that it will be done
    some day.

    Throw in some mod_rewrite stuff and having PHP figure out when to do 403,
    and when to complain that it can't read a file, will be probably be *way*
    too much hackery.
  • Rasmus Lerdorf at Jan 11, 2005 at 7:06 pm

    Richard Lynch wrote:
    You'd be confusing the HELL out of me to have PHP sending out a 403
    because it couldn't read the included file after it already managed to
    read index.php and connect.inc
    Right, I don't disagree with you that it would be confusing and
    inconsistent which is why no such magic is being done. To me a PHP
    script with incorrect permissions is really no different from a PHP
    script with a syntax error in it. In both cases you would want to know
    you screwed up and you just have to manage where these error messages
    should appear.

    -Rasmus
  • Rasmus Lerdorf at Jan 10, 2005 at 11:17 pm

    Jason Morehouse wrote:
    Jonel Rienton wrote:
    man chmod, i gather you're new to linux/*nix

    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.

    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.
    Because Apache doesn't try to open the file. And you should never have
    display_errors enabled on a production server. That's for development
    purposes. Always log your php errors to a file when you put a server
    online.

    -Rasmus
  • Bret Hughes at Jan 10, 2005 at 11:32 pm

    On Mon, 2005-01-10 at 15:21, Jason Morehouse wrote:
    Jonel Rienton wrote:
    man chmod, i gather you're new to linux/*nix
    I don't need a lesson in file permissions, thanks. Apache runs as
    nobody. The problem isn't trying to get apache to display test.php,
    it's having it display the proper 403 error page, rather than a php
    error when it doesn't have access to a page.

    Each page, test.html and test.php have the same permissions. The html
    page gives the expected 403 error message when I try and access it
    (thats what I want). The other, php script doesn't. This is a security
    concern for me as it reveals paths on my system in the event a page has
    the wrong permissions. Why does apache not server the 403 on the php
    page? Maybe this is better off in the apache list.

    Ahh. well I guess everyone got a refresher on *nix perms at least :) I
    see what you are concerned about but am wondering if relying on the
    underlying file system perms is a good thing to begin with. Still, I
    have no answer for your question. It is an interesting one and I hope
    you will enlighten us once you find the answer.

    FWIW it sounds to me to be a php issue. Apache sees the php extension
    and passes it off to php who then pukes on the perms.

    Bret
  • Richard Lynch at Jan 11, 2005 at 12:06 am

    On Jan 10, 2005, at 12:49 PM, Jason Morehouse wrote:
    Hello. I'm not sure if this is an apache problem or php... but
    wondering if anyone has come across the same problem.

    -rw------- 1 root root test.html
    -rw------- 1 root root test.php

    Trying to access test.html via a browser servers up the apache 403
    error page. The test.php however produces:

    Warning: Unknown: failed to open stream: Permission denied in Unknown
    on line 0 Warning: Unknown: Failed opening '/www/test.php' for
    inclusion (include_path='.:/www/php') in Unknown on line 0
    Ahhhh! Now we see the question! Why doesn't it yield 403 like it "should"

    First and foremost, use php.ini or httpd.conf or .htaccess to *NOT* let
    PHP send error messages OF ANY KIND to the browser on a production site.

    [You could also use ini_set within a script if the file in question is to
    be include'd into other files.]

    You should do this anyway.

    Admittedly, your server still behaves not quite like you want, as *.html
    yields a 403 response, and *.php yields a 200 response, and a page of no
    content. But at least the Bad Guys don't see your server internals.

    I don't think there's any way you can configure Apache to pre-empt the PHP
    trying to read the file -- though I presume Apache *could* be altered to
    behave that way... Except it would be rather difficult for Apache to
    'know' a priori what User PHP runs as, given suexec, CGI setups, etc...

    Depending on your application, you might be able to "wrap" all the access
    to files through a known good PHP file, and then use PHP error handling
    (http://php.net/set_error_handler) to determine if this error occurred,
    and then send a 403 header.

    Probably an Apache list would be better suited to knowing for sure any way
    around this... You could maybe tweak the PHP source to detect this
    condition and send 403 instead of trying to include() the file, which is
    what it seems to be doing.
  • Jason Morehouse at Jan 11, 2005 at 1:00 am

    Richard Lynch wrote:
    Ahhhh! Now we see the question! Why doesn't it yield 403 like it "should"

    First and foremost, use php.ini or httpd.conf or .htaccess to *NOT* let
    PHP send error messages OF ANY KIND to the browser on a production site.

    [You could also use ini_set within a script if the file in question is to
    be include'd into other files.]

    You should do this anyway.

    Admittedly, your server still behaves not quite like you want, as *.html
    yields a 403 response, and *.php yields a 200 response, and a page of no
    content. But at least the Bad Guys don't see your server internals.

    I don't think there's any way you can configure Apache to pre-empt the PHP
    trying to read the file -- though I presume Apache *could* be altered to
    behave that way... Except it would be rather difficult for Apache to
    'know' a priori what User PHP runs as, given suexec, CGI setups, etc...

    Depending on your application, you might be able to "wrap" all the access
    to files through a known good PHP file, and then use PHP error handling
    (http://php.net/set_error_handler) to determine if this error occurred,
    and then send a 403 header.

    Probably an Apache list would be better suited to knowing for sure any way
    around this... You could maybe tweak the PHP source to detect this
    condition and send 403 instead of trying to include() the file, which is
    what it seems to be doing.
    Yeah, thanks all. I usually have error logging off, but enabled it from
    time to time when hunting down bugs (and forget to add it back).

    Anyway, I guess I'll have to deal with just blank pages coming up in the
    event of a .php 403... not a big deal really, I just prefer constancy.

    I still don't really get why apache hands parsing off to php when it
    knows it doesn't have read access to the file, but I'll save that for
    another list!

    Thanks again.
    -J


    --
    Jason Morehouse
    Vendorama - Create your own online store
    http://www.vendorama.com
  • Rasmus Lerdorf at Jan 11, 2005 at 2:53 am

    Jason Morehouse wrote:
    I still don't really get why apache hands parsing off to php when it
    knows it doesn't have read access to the file, but I'll save that for
    another list!
    It could check, I suppose, but it doesn't always know that just because
    it can't access the file the receiver won't be able to. For example,
    mod_suexec can run something to handle the request as a different user
    id, so Apache wouldn't have any clue whether or not the destination
    handler is able to read the file or not.

    Other times Apache hands something off to PHP which may not be treated
    as a file at all by PHP. For example, you might have an auto_prepend
    script that looks at the filename itself and uses that to do something
    without actually trying to access the file.

    A quick little Apache module that runs in the filename translation hook
    or perhaps the auth hook would solve this particular problem for you.
    Shouldn't be more than a 5-liner but it isn't something Apache can do by
    default without potentially breaking many things out there.

    -Rasmus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-general @
categoriesphp
postedJan 10, '05 at 6:54p
activeJan 11, '05 at 7:25p
posts24
users12
websitephp.net

People

Translate

site design / logo © 2022 Grokbase