Quelles sont les autorisations de répertoire recommandées?


145

Je me prépare à déployer un site Drupal 7 et je ne trouve aucune documentation sur les autorisations recommandées pour les fichiers et les répertoires sensibles à la sécurité.

Plus précisément default/files/(également les sous-répertoires?) settings.php, .htaccessEt tout ce dont je devrais être au courant.


1
Il existe également une réponse ici: drupal.stackexchange.com/questions/52695/…
Free Radical

Il existe un blog qui explique cela à merveille et en couvre tous les aspects de manière abstraite. technologymythbuster.blogspot.com/2018/06/…
Kalpesh Popat

Réponses:


69

Votre serveur Web doit pouvoir lire tous les fichiers mais ne pas y écrire. Si votre site implique le téléchargement de fichiers, accordez au serveur la permission d'écrire dans ce seul dossier.

Plus d'informations sur la manière de le configurer, ainsi que sur certaines choses qui peuvent arriver si vous ne le faites pas, sont disponibles dans la documentation Drupal .


13
Ce n'est pas le cas du répertoire sites / default / files, qui doit être accessible en écriture par le serveur Web, sinon vous aurez beaucoup de problèmes.
Rooby

3
@rooby La deuxième phrase clarifie cela.
Kenorb

14
Bien que le message "Si votre site implique le téléchargement de fichiers", ce n’est pas la seule raison pour laquelle vous pourriez avoir besoin d’un accès en écriture au répertoire des fichiers. Un exemple très courant est l’agrégation js / css, qui consiste à télécharger des fichiers par des utilisateurs indépendants. D'autres modules peuvent également s'attendre à ce que ce répertoire soit accessible en écriture.
Rooby

91

Cette page drupal, comme tant d’autres, est très longue et déroutante. Mais il contient ce message de Jason, qui a mis le doigt dessus:

Publié par Jason Sale le 1 novembre 2010 à 12h40

Merci d’avoir écrit tout cela, mais tout ce que je souhaite, ainsi que 99% des lecteurs de cette page, c’est une liste de chiffres à côté d’une liste de dossiers.

  • /default sur 755
  • /default/files y compris tous les sous-dossiers et fichiers sur 744 (ou 755)
  • /default/themes y compris tous les sous-dossiers et fichiers sur 755
  • /default/modules y compris tous les sous-dossiers et fichiers sur 755
  • /default/settings.phpet /default/default.settings.phpsur 444

7
Le sujet est long et déroutant. La page correspond à la réalité de la situation.
greggles

17
... des documents Drupal! Et c'est pourquoi il faut le changer en quelque chose de simple et compréhensible immédiatement! Surtout en matière de sécurité. JUSTE PARCE QUE c'est une question de sécurité! Parce que cela nous appartient à tous. Un serveur infecté n'est pas seulement un problème d'utilisateurs Drupal inexpérimentés. C'est un problème de nous tous alors. Il n’est donc pas très utile de conserver des documents complexes et mal écrits inspirés par le narcissme des développeurs, afin de montrer la complexité et la complexité et de voir à quel point eux-mêmes peuvent le gérer. Je ne vois pas l'intérêt de laisser de côté un simple graphique d'arborescence d'autorisations de fichiers. webchick accepte cela.
Nilsun

3
Pourquoi avoir 755 sur / default / files? Cela ne devrait-il pas toujours être 744 juste au cas où quelqu'un parviendrait à télécharger quelque chose de malveillant en piratant le front-end (ou par le biais d'une mauvaise configuration)? Y a-t-il une raison d'avoir 755? Qu'en est-il / tmp?
Webdrips le

1
Le fichier settings.php doit être 440. "Autres" ne doit pas pouvoir voir settings.php. 740 si vous voulez pouvoir y écrire sans commandes sudo.
Bryden

juste curieux de savoir pourquoi les fichiers .htaccess dans les fichiers et les dossiers tmp doivent être écrits par le serveur Web? N'est-il pas sécuritaire de le marquer 444 comme suit: settings.php. La raison pour laquelle je me pose la question est de savoir si junkfile.php peut être téléchargé par un pirate informatique dans un dossier via le serveur Web, puis le fichier .htaccess pourrait être remplacé. ai-je raison?
kiranking

82

Mon travail sur la création d'un nouveau site Drupal sur un serveur consiste à faire en sorte qu'un utilisateur fasse partie du groupe de serveurs Web (généralement Apache) et que cet utilisateur soit propriétaire de tous les fichiers Drupal. Sur Ubuntu, ce sont les commandes pour obtenir cette configuration:

# Create a new example user, setting up /var/www/example as their home dir.
useradd -s /bin/bash -d /var/www/example -m example

# Now add that user to the Apache group. On Ubuntu/Debian this group is usually
# called www-data, on CentOS it's usually apache.
usermod -a -G www-data example

# Set up a password for this user.
passwd example

Une fois cette configuration configurée, je me connecte en tant qu'utilisateur et installe Drupal sous / var / www / example / docroot ou similaire, puis crée le répertoire des fichiers à la main et copie le fichier settings.php. Puisque nous nous connectons en tant qu'exemple d'utilisateur avant de copier dans Drupal, la propriété et les autorisations de nos fichiers doivent automatiquement être correctement configurées sur tous les fichiers et scripts Drupal principaux (y compris les fichiers .htaccess).

su - example
cd docroot
cp sites/default/default.settings.php sites/default/settings.php

# Temporarily give the web server write permissions to settings.php
chgrp www-data sites/default/settings.php
chmod g+w sites/default/settings.php

Maintenant, configurons le répertoire de fichiers.

# Create the directory.
mkdir sites/default/files

# Now set the group to the Apache group. -R means recursive, and -v means 
# verbose mode.
chgrp -Rv www-data sites/default/files

Ensuite, nous allons configurer les autorisations pour que le serveur Web puisse toujours écrire dans tous les fichiers de ce répertoire. Nous faisons cela en utilisant 2775 dans notre commande chmod. Le 2 signifie que l'identifiant du groupe sera préservé pour tout nouveau fichier créé dans ce répertoire. Cela signifie que www - data sera toujours le groupe sur tous les fichiers, garantissant ainsi que le serveur Web et l'utilisateur auront toujours les droits d'écriture sur tous les nouveaux fichiers placés dans ce répertoire. Le premier 7 signifie que le propriétaire (exemple) peut utiliser R (Lecture), W (Écriture) et X (Exécuter) tous les fichiers de ce fichier. Le second 7 signifie que ce groupe (www-data) peut également RW et X n’importe quel fichier de ce répertoire. Enfin, le 5 signifie que les autres utilisateurs peuvent utiliser les fichiers R et X, mais pas écrire.

 chmod 2775 sites/default/files

S'il y a des fichiers existants dans ce répertoire, assurez-vous que le serveur Web dispose d'une autorisation d'écriture.

 chmod g+w -R sites/default/files

Drupal est maintenant prêt à être installé. Lorsque vous avez terminé, il est TRÈS important de revenir à settings.php et de vous assurer que tous les utilisateurs ont uniquement des autorisations de lecture.

 chmod 444 sites/default/settings.php

C'est ça! Cette configuration garantit que vous évitez toute situation dans laquelle l'utilisateur qui détient le répertoire ou le serveur Web ne peut pas écrire / modifier / supprimer des fichiers dans le répertoire des fichiers.


N'est-il pas sécuritaire de définir .htacess sur 444 jsut en tant que settings.php? de toute façon, ce fichier est rarement mis à jour dans le noyau de Drupal.
kiranking

Vous pouvez définir .htaccess sur 444, mais cela ajoutera un casse-tête supplémentaire lors de la mise à niveau de Drupal et ne rendra pas votre site plus sécurisé.
Q0rban

30

Le dossier de fichiers Drupal doit être accessible en écriture sur le serveur Web. Le moyen le plus sûr de le faire est de changer le groupe et de le rendre accessible en écriture, comme ceci:

chgrp www-data sites/default/files
chmod g+w sites/default/files

Le dossier de téléchargement de fichiers mis à part, le plus sûr est chmod 644 pour tous les fichiers, 755 pour les répertoires.

Cela pourrait être accompli comme ceci (lorsqu'il est exécuté dans le dossier Drupal-site, .c'est pour le chemin actuel):

find . -type f | xargs chmod 644
find . -type d | xargs chmod 755

N'oubliez pas que vous devrez chmod g+wredéfinir la configuration après avoir exécuté la commande ci-dessus, car elles réinitialiseront le chmod sur tous les fichiers et dossiers.


2
Cette réponse suppose: vous êtes sur Ubuntu. Votre site est le seul à fonctionner sur ce serveur. De plus, cela ne résout le problème qu’une seule fois au lieu de le résoudre automatiquement (par exemple, en modifiant le paramètre umask).
greggles

Pas nécessairement Ubuntu, et c'est toujours une mesure utile, même si plusieurs sites fonctionnent sur le même serveur. Changer le umask (qui, espérons-le, devrait déjà avoir ces paramètres) n'est pas quelque chose que je recommanderais aux personnes peu familiarisées avec Linux. Je sais que ce n’est pas une sécurité parfaite, mais ne laissons pas la perfection être l’ennemi du bien ici.
Mikel

Sur un multisite, je cours chgrp -R www-data sites/*/fileset je chmod -R g+w sites/*/filessupprime les erreurs de page d'état.
leymannx

20

Tout conseil de "chmod blah" ou "chown X" n'a pas de sens sans savoir: quel est l'utilisateur par défaut: groupe sur les fichiers, ni quel utilisateur et quels groupes votre serveur Web est exécuté.

Les documents Drupal auxquels d'autres ont fait référence sont assez bons sur le sujet, mais le module de révision de la sécurité est une autre ressource qui permet de s'assurer que tout est correctement configuré.


9

Je répondrai compte tenu du cas où les fichiers sont créés sur le serveur en utilisant FTP, en utilisant des informations d'identification différentes de celle sous laquelle le serveur Web est exécuté (normalement, Apache ne s'exécute que sous la forme personne / personne). Cela signifie que l'utilisateur qui possède les fichiers créés manuellement avant d'exécuter le programme d'installation de Drupal (qui inclut également les fichiers téléchargés sur le serveur à partir de l'archive Drupal) n'est pas l'utilisateur utilisé pour exécuter le serveur Web (ni le nom d'utilisateur ni le groupe ne correspond). . Ce scénario s'applique également au cas où ces fichiers sont créés à l'aide de SSH.

  • Le fichier settings.php doit être accessible en écriture à partir du programme d'installation de Drupal, mais une fois l'installation terminée, il est suggéré de le rendre en lecture seule (le programme d'installation le suggère, et Drupal vérifiera périodiquement si le fichier est vraiment en lecture seule). Dans le scénario que je décris, l'autorisation de ce fichier doit au moins être 644.
  • Les fichiers .htaccess (présents à au moins deux endroits) doivent avoir l'autorisation 644. L'utilisateur qui a créé le fichier doit toujours pouvoir écraser le fichier. Dans le cas où une prochaine version de Drupal serait livrée avec un fichier .htaccess qui a été mis à jour (cela s'est déjà produit une fois, quand il a été ajouté une ligne à ce fichier pour éviter un problème de sécurité). Il est également possible de définir les autorisations sur 444, mais dans ce cas, les autorisations doivent être redéfinies sur 644 lorsque le fichier doit être mis à jour.
  • Le répertoire contenant les fichiers créés par les modules (le default/filesrépertoire) doit être (pour l'utilisateur affecté aux processus du serveur Web, qui est alors l'utilisateur affecté aux scripts PHP s'exécutant sur ce serveur Web):
    • lisible
    • en écriture
    • traversable (les modules doivent pouvoir atteindre default/files/<directory-used-by-the-module>/<sub-directory-used-by-the-module>)

après avoir lu le fil de discussion à drupal.org/node/244924 et plus précisément à drupal.org/node/244924#comment-8186447, aucune des différentes méthodes fournies pour obtenir des fichiers téléchargés n’avait que 660 RW-RW ----. sans bit d'exécution. N'est-ce pas le principal problème de sécurité?
kiranking

8

Autorisations de fichier / répertoire recommandées:

  • Drupal Webroot devrait être lisible dans le monde entier (voir: updater.inc ): 0755
  • pour les répertoires de téléchargement public: 0755 ou 0775
  • pour les répertoires de téléchargement privés: 0750 ou 0770
  • pour les fichiers téléchargés publics: 0644 ou 0664
  • pour les fichiers téléchargés privés: 0640 ou 0660
  • pour .htaccess dans les répertoires de téléchargement (voir: file_create_htaccess () ): 0444 (par défaut) ou 0644
  • pour settings.php en lecture seule pour tous (et autres fichiers confidentiels): 0440
  • pour tous les autres annuaires Web: 0755
  • pour tous les autres fichiers Web: 0644

Propriété de fichier / répertoire recommandée:

  • le propriétaire de tous les répertoires / fichiers de téléchargement doit être défini sur utilisateur Apache,
  • le propriétaire de tous les répertoires / fichiers web / sources doit être défini sur un utilisateur non-Apache,
  • (éventuellement) le groupe de toutes les sources doit être défini sur le groupe Apache,

Voici les variables qui contrôlent les autorisations de répertoire / fichier par défaut pour les nouveaux éléments:

file_chmod_directory: 0775
file_chmod_file: 0664

Voici un script pour la fixation des autorisations: fix-permissions.sh


Lire la suite:


Voici le script que j'utilise pour corriger les autorisations sur l'hôte distant pour les répertoires publics / privés:

#!/bin/sh -e
# Script to correct public/private directory and files permissions.
[ -z "$1" ] && { echo Usage: $0 @remote.dst; exit 1; }

DST="$1" && shift
GET_HTTP_GROUP='ps axo user,group,comm | egrep "(apache|httpd)" | grep -v ^root | uniq | cut -d\  -f 1'

drush $* $DST ssh 'PUB=$(drush dd %files) && PRIV=$(drush dd %private) && AGROUP=$('"$GET_HTTP_GROUP"') && chgrp -vR $AGROUP $PUB $PRIV && chmod -vR u+rwX,g+rwX,o+rX $PUB $PRIV'

Remarque: Le code ci-dessus essaiera de récupérer le groupe Apache et de le définir comme GET_HTTP_GROUPvariable.


très bel aide-mémoire, marqué d'un signet. Bon travail ..
kiranking

4

Ce script shell se trouve au bas de cette page: https://www.drupal.org/node/244924

Je l'exécute de temps en temps pour m'assurer que mes autorisations sont correctement configurées.

#!/bin/bash
# Help menu
print_help() {
cat <<-HELP
This script is used to fix permissions of a Drupal installation
you need to provide the following arguments:
1) Path to your Drupal installation.
2) Username of the user that you want to give files/directories ownership.
3) HTTPD group name (defaults to www-data for Apache).
Usage: (sudo) bash ${0##*/} --drupal_path=PATH --drupal_user=USER --httpd_group=GROUP
Example: (sudo) bash ${0##*/} --drupal_path=/usr/local/apache2/htdocs --drupal_user=john --httpd_group=www-data
HELP
exit 0
}
if [ $(id -u) != 0 ]; then
  printf "**************************************\n"
  printf "* Error: You must run this with sudo. *\n"
  printf "**************************************\n"
  print_help
  exit 1
fi
drupal_path=${1%/}
drupal_user=${2}
httpd_group="${3:-www-data}"
# Parse Command Line Arguments
while [ $# -gt 0 ]; do
  case "$1" in
    --drupal_path=*)
      drupal_path="${1#*=}"
      ;;
    --drupal_user=*)
      drupal_user="${1#*=}"
      ;;
    --httpd_group=*)
      httpd_group="${1#*=}"
      ;;
    --help) print_help;;
    *)
      printf "***********************************************************\n"
      printf "* Error: Invalid argument, run --help for valid arguments. *\n"
      printf "***********************************************************\n"
      exit 1
  esac
  shift
done
if [ -z "${drupal_path}" ] || [ ! -d "${drupal_path}/sites" ] || [ ! -f "${drupal_path}/core/modules/system/system.module" ] && [ ! -f "${drupal_path}/modules/system/system.module" ]; then
  printf "*********************************************\n"
  printf "* Error: Please provide a valid Drupal path. *\n"
  printf "*********************************************\n"
  print_help
  exit 1
fi
if [ -z "${drupal_user}" ] || [[ $(id -un "${drupal_user}" 2> /dev/null) != "${drupal_user}" ]]; then
  printf "*************************************\n"
  printf "* Error: Please provide a valid user. *\n"
  printf "*************************************\n"
  print_help
  exit 1
fi
cd $drupal_path
printf "Changing ownership of all contents of "${drupal_path}":\n user => "${drupal_user}" \t group => "${httpd_group}"\n"
chown -R ${drupal_user}:${httpd_group} .
printf "Changing permissions of all directories inside "${drupal_path}" to "rwxr-x---"...\n"
find . -type d -exec chmod u=rwx,g=rx,o= '{}' \;
printf "Changing permissions of all files inside "${drupal_path}" to "rw-r-----"...\n"
find . -type f -exec chmod u=rw,g=r,o= '{}' \;
printf "Changing permissions of "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
cd sites
find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
printf "Changing permissions of all files inside all "files" directories in "${drupal_path}/sites" to "rw-rw----"...\n"
printf "Changing permissions of all directories inside all "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
for x in ./*/files; do
    find ${x} -type d -exec chmod ug=rwx,o= '{}' \;
    find ${x} -type f -exec chmod ug=rw,o= '{}' \;
done
echo "Done setting proper permissions on files and directories"
Copy the code above to a file, name it "fix-permissions.sh" and run it as follows:
sudo bash fix-permissions.sh --drupal_path=your/drupal/path --drupal_user=your_user_name

Note: The server group name is assumed "www-data", if it differs use the --httpd_group=GROUP argument.

2

De plus, si vous utilisez fastcgi, le php s'exécute en tant qu'utilisateur et aura accès à tous les fichiers auxquels l'utilisateur a accès, à moins que vous n'essayiez délibérément de l'éviter.


1

Cela m'a aidé avec mes problèmes d'autorisation OSX. Je l'ai trouvé dans https://www.drupal.org/node/244924#comment-3741738 par un utilisateur du protoplasme. J'étais comme lui avoir des problèmes après une migration.

[root@localhost]cd /path_to_drupal_installation/sites
[root@localhost]find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
[root@localhost]find . -name files -type d -exec find '{}' -type f \; | while read FILE; do chmod ug=rw,o= "$FILE"; done
[root@localhost]find . -name files -type d -exec find '{}' -type d \; | while read DIR; do chmod ug=rwx,o= "$DIR"; done

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.