Tag Archives: PHP

open_basedir

Limit the files that can be accessed by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off.

When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it’s not possible to avoid this restriction with a symlink. If the file doesn’t exist then the symlink couldn’t be resolved and the filename is compared to (a resolved) open_basedir .

open_basedir can affect more than just filesystem functions; for example if MySQL is configured to use mysqlnd drivers, LOAD DATA INFILE will be affected by open_basedir . Much of the extended functionality of PHP uses open_basedir in this way.

The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir().

In httpd.conf, open_basedir can be turned off (e.g. for some virtual hosts) the same way as any other configuration directive with “php_admin_value open_basedir none”.

Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited.

The restriction specified with open_basedir is a directory name since PHP 5.2.16 and 5.3.4. Previous versions used it as a prefix. This means that “open_basedir = /dir/incl” also allowed access to “/dir/include” and “/dir/incls” if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: open_basedir = /dir/incl/

The default is to allow all files to be opened.

Note:

As of PHP 5.3.0 open_basedir can be tightened at run-time. This means that if open_basedir is set to /www/ in php.ini a script can tighten the configuration to /www/tmp/ at run-time with ini_set(). When listing several directories, you can use the PATH_SEPARATOR constant as a separator regardless of the operating system.

Race Condition

A race condition or race hazard is the behavior of a software where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended.

Race conditions can occur especially in multithreaded or distributed software programs.

User Defined Errors

• Userland code may trigger custom errors

trigger_error(
 "something went wrong",
 E_USER_WARNING);

• These errors may be handled with a custom error handler function

function myHandler($code, $text, $file, $line) {
 
 if ($code == E_USER_WARNING) {
 echo 'WARNING: ' .
 htmlspecialchars($text);
 return true;
 }
 
 return false;
}

• If the custom error handler function returns true, php´s error handling does not kick in

• Custom error handler function needs to be registered using set_error_handler(“myHandler”).

Example

<?php
 function myErrorHandler($errno, $errstr, $errfile, $errline) {
 echo "<b>Custom error:</b> [$errno] $errstr<br>";
 echo " Error on line $errline in $errfile<br>";
 }

set_error_handler("myErrorHandler");
 
 $test=2;

if ($test>1) {
 trigger_error("A custom error has been triggered");
 }
?>

Error Display

• By default, all errors included in error_reporting are reported in php´s output

• This behavior can – and should – be deactivated on production systems using the display_errors = off php.ini setting

• Errors should still be logged, using the log_errors = on php.ini setting

• The error log is a file set in the error_log php configuration setting. if set to syslog, errors are logged in the system log independent on the operating system used.

Error Levels

• PHP supports several types of errors

o notices at runtime
o errors during parsing (prevents code execution)
o warnings at runtime
o fatal errors at runtime (stop code execution)
o Core errors and warnings
o user-defined notices, warnings, and errors

• php configuration setting error_reporting, or php’s error_reporting() function may be used to define which kinds of errors shall be reported

• Value is an integer, or – much more convenient – a bitmask based on pre-defined constants

o E_NOTICE, E_PARSE, E_WARNING, E_ERROR

o E_CORE_WARNING, E_CORE_ERROR

o E_USER_NOTICE, E_USER_WARNING ,E_USER_ERROR

o E_STRICT(„best practices“ notices)

o E_DEPRECATED (features that might disappear in future php versions)

o E_ALL(everything) o and some more

• Typical production setting: E_ALL & ~E_DEPRECATED & ~E_STRICT

Exception Handling

Exception handling is used to change the normal flow of the code execution if a specified error (exceptional) condition occurs. This condition is called an exception.

Exceptions or errors (more on that see below) end code execution, unless they are handled with try-catch.

try {
// code that throws an Exception
} catch (Exception $ex) {
// Exception is handled, code
continues
}

Several catch statements may be used to differentiate between several kinds of exceptions and errors.

try {
// code that throws an Exception
} catch (CustomExceptionClass $ex) {
// custom Exception is handled
} catch (Exception $ex) {
// Exception is handled
} catch (Error $err) {
// Error is handled
}

Several errors may be handled with the same code.

try {
// code that throws an Exception
} catch (Exception | CustomException $ex)
{
// custom Exception and Exception
}

Optional finally block contains code that runs after the trycatch block, no matter whether an error was caught or not

This is what normally happens when an exception is triggered:

  • The current code state is saved
  • The code execution will switch to a predefined (custom) exception handler function
  • Depending on the situation, the handler may then resume the execution from the saved code state, terminate the script execution or continue the script from a different location in the code

Error Class

• Since php 7, many errors php reports now throw an error exception, not a fatal error as before.

• Subclasses of error exist for the specific type of error, such as parseerror or typeerror.

• To facilitate backwards compatibility, error is not derived from exception.

• Both error and exception implement the throwable interface