Linux Attitude

Niveau :      
Résumé : chroot apache2

Puisqu'on me met au défi, je vous propose de chrooter apache sans devoir installer un chroot debian complet. Tout comme pour bind, la technique n'est pas spécifique debian et vous pourrez facilement l'adapter à votre situation, de plus elle marche aussi pour apache 1.3.

Pour commencer, il vous faut un apache (2 c'est aussi bien) ainsi que l'outil miracle : mod_chroot. Celui-ci se trouve chez debian dans le paquet libapache2-mod-chroot. Son comportement est simple, il imite celui de bind. Il attend que l'application soit chargée pour effectuer l'appel système chroot(2), ce qui fait qu'il ne nécessite pas d'avoir toutes les dépendances du binaire dans le chroot.

Maintenant configurons-le, la notion de chroot étant globale au serveur apache en entier, c'est /etc/apache2/apache2.conf que nous allons modifier. Il suffit d'ajouter la ligne :

ChrootDir /srv/http

En supposant que vous avez chargé le module (avec a2enmod de préférence sous debian et une ligne LoadModule pour les autres), c'est presque fini. Vous devez maintenant relire toute votre configuration, car certaines directives sont relatives au nouveau root. En particulier les directives DocumentRoot et Directory (en pratique tous les fichiers lus dynamiquement)

Ensuite vous aurez besoin d'un minimum de fichiers dans ce chroot, heureusement ce minimum est très léger. Il nous faut un répertoire /var/run et l'accès au pid depuis l'intérieur et l'extérieur du chroot :

mkdir -p /srv/http/var/run
# attention, un lien symbolique dans l'autre sens ne fonctionnerait pas
# utilisez http.pid sur une redhat
ln -s /srv/http/var/run/apache2.pid /var/run/apache2.pid

Et voilà !!!
N'oubliez pas de mettre les données du site dans votre nouveau chroot.

Des racines profondes

Vous avez votre chroot utilisable directement depuis l'extérieur du chroot avec les scripts d'init naturels. Mais attention, quelques petites restrictions :

• les commandes reload et force-reload ne marcheront pas
  • pour cette raison, vous devrez aussi modifier votre configuration de logrotate
• les cgi ne fonctionneront pas tels quels, ils doivent être placés intégralement (avec leurs dépendances) dans le chroot
  • en particulier suexec pour php
• les modules peuvent avoir besoin de lire des fichiers, attention à bien convertir leur configuration
  • en particulier php
  • les modules pear installables tels quels avec la commande pear
• par défaut php/mysql utilise une socket unix pour parler a localhost, vous devez modifier vos scripts pour utiliser explicitement une connexion à 127.0.0.1 si besoin (ou dire a mysql de stocker sa socket dans /srv/http/tmp)
• apache mpm worker a besoin d'une bibliothèque supplémentaire dans le chroot

D'autres petits détails.

Les solutions sont peu variées :

• pour les bibliothèques dynamiques requises par certains modules, il suffit de demander à apache de les précharger avec la commande LoadFile

# pour le mpm worker
LoadFile /lib/libgcc_s.so.1
# pour la résolution dns dans les logs (en fait désactivez la fonctionnalité ça vous évitera des soucis)
LoadFile /lib/libnss_dns.so.2

• pour les bibliothèques php style pear, un déplacement avec un lien symbolique (de l'extérieur du chroot vers l'intérieur et non pas le contraire :-) devrait vous permettre la gestion depuis l'extérieur du chroot

mkdir -p /srv/http/usr/share/
mv /usr/share/php /srv/http/usr/share/
ln -s /srv/http/usr/share/php /usr/share/php

• pour les commandes reload, il y a du travail car vous devrez faire de même pour les fichiers de configuration, les logs, les fichiers de configuration de la libc, les modules, certaines bibliothèques partagées ... il est bien plus simple de ne pas les utiliser.