<?xml version="1.0" encoding="utf-8"?>

<chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">

<title>Installé en tant que module Apache</title>

<simpara>

Lorsque <acronym>PHP</acronym> est utilisé en tant que module Apache, celui-ci hérite des

permissions accordées à l'utilisateur faisant tourner Apache (par défaut,

l'utilisateur "nobody"). Ceci a plusieurs impacts sur la sécurité et

les autorisations.

Par exemple, lors de l'utilisation de <acronym>PHP</acronym> pour accéder à une base de données, à

moins que la base n'ait un système de droits d'accès interne, il faudra

la rendre accessible à l'utilisateur "nobody". Cela signifie qu'un

script mal intentionné peut accéder à la base et la modifier, sans

identification. Il est même possible qu'un robot accède à une page

d'administration, et détruise toutes les bases de données. Il est possible de se protéger

contre cela avec les autorisations Apache, ou définir un

modèle d'accès propre en utilisant LDAP, des fichiers &htaccess;, etc. et inclure ce code

dans les scripts <acronym>PHP</acronym>.

</simpara>

<simpara>

Souvent, lorsqu'on a établi les droits de l'utilisateur <acronym>PHP</acronym> (ici,

l'utilisateur Apache) pour minimiser les risques, on s'aperçoit que

<acronym>PHP</acronym> ne peut plus écrire de fichiers dans les répertoires des utilisateurs.

Ou encore, qu'il ne peut plus accéder à, ou modifier, une base de données privée.

En somme, les sécurités mises en place empêchent à la fois l'écriture de bons et de mauvais fichiers,

en même temps que les bonnes et mauvaises opérations en bases de données.

</simpara>

<simpara>

Arrivé là, une erreur de sécurité fréquente est de donner à l'utilisateur Apache

les droits de superadministrateur ("root"), ou d'accroître les possibilités d'Apache

d'une quelconque autre façon.

</simpara>

<simpara>

Donner de telles permissions à l'utilisateur Apache est extrêmement

dangereux, et pourrait compromettre tout le système ; en conséquence, l'utilisation de sudo,

de chroot, ou de toute autre solution permettant de fonctionner en tant que superadministrateur

("root"), ne devrait pas être envisagée par toute personne qui ne soit pas experte en sécurité.

</simpara>

<simpara>

Il existe des solutions plus simples. En utilisant

<link linkend="ini.open-basedir">open_basedir</link>, il est possible de contrôler et restreindre

les dossiers qui seront accessibles par <acronym>PHP</acronym>. Il est également possible de

créer des aires de restrictions Apache, pour limiter les activités

en provenance du web à des fichiers qui ne soient en rapport ni avec des utilisateurs,

ni avec le système.

</simpara>

</chapter>