web-dev-qa-db-fra.com

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

Je me prépare à déployer un site Drupal 7 et je ne trouve aucune documentation sur la définition des autorisations de fichier et de répertoire recommandées pour la sécurité.

Plus précisément default/files/ (également des sous-répertoires?), settings.php, .htaccess et tout ce que je dois savoir.

145
ack

Votre serveur Web devrait pouvoir lire tous les fichiers mais pas y écrire. Si votre site implique le téléchargement de fichiers, accordez au serveur l'autorisation d'écrire uniquement dans ce dossier.

Plus d'informations sur la façon de configurer cela, ainsi que certaines choses qui peuvent arriver si vous ne le faites pas, sont disponibles dans le Drupal docs .

68
Paul Jones

Cette page drupal comme tant d'autres est très longue et déroutante. Mais il contient ce post de Jason, qui a mis le doigt sur la tête:

Publié par Jason Sale le 1 novembre 2010 à 12 h 40

Merci d'avoir écrit ceci et tout, mais tout ce que moi et 99% des personnes lisant cette page veulent vraiment, c'est une liste de numéros à 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.php et /default/default.settings.php sur 444
91
ErichBSchulz

Ma pratique autour de la création d'un nouveau site Drupal sur un serveur est d'avoir un utilisateur qui fait partie du groupe de serveurs Web (généralement Apache), et que cet utilisateur possède tous les Drupal. Sur Ubuntu, voici 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 que je l'ai installé, je vais me connecter en tant qu'utilisateur et installer Drupal dans/var/www/example/docroot ou similaire, puis créer le répertoire de fichiers à la main et copier sur le fichier settings.php. Puisque nous nous connectons en tant qu'utilisateur exemple avant de copier dans Drupal, notre propriété de fichier et nos autorisations doivent être correctement configurées correctement sur tous les fichiers et scripts de base Drupal (y compris .htaccess) des dossiers).

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

Configurons maintenant le répertoire des 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 des autorisations afin que le serveur Web puisse toujours écrire dans n'importe quel fichier qui se trouve dans ce répertoire. Pour ce faire, nous utilisons 2775 dans notre commande chmod. Le 2 signifie que l'ID de groupe sera conservé pour tous les nouveaux fichiers créés 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 autorisations d'écriture sur tous les nouveaux fichiers placés dans ce répertoire. Le premier 7 signifie que le propriétaire (exemple) peut R (lire) W (écrire) et X (exécuter) tous les fichiers ici. Le second 7 signifie que le groupe (www-data) peut également R W et X tous les fichiers de ce répertoire. Enfin, le 5 signifie que d'autres utilisateurs peuvent R et X fichiers, 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 a des autorisations d'écriture dessus.

 chmod g+w -R sites/default/files

Maintenant Drupal est prêt à être installé. Une fois terminé, il est TRÈS important de revenir à settings.php et de s'assurer que tous les utilisateurs n'ont que des autorisations de lecture.

 chmod 444 sites/default/settings.php

C'est ça! Cette configuration vous permet d'éviter toute situation dans laquelle l'utilisateur propriétaire du répertoire ou le serveur Web ne peut pas écrire/modifier/supprimer des fichiers dans le répertoire des fichiers.

81
q0rban

Le dossier de fichiers Drupal doit être accessible en écriture par le serveur Web. La façon la plus sûre 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, le . est pour le chemin actuel):

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

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

31
mikl

Tout conseil à "chmod blah" ou "chown X" n'a pas de sens sans savoir: quel est l'utilisateur par défaut: group sur les fichiers et quel utilisateur et quels groupes votre serveur web exécute.

Les Drupal documents auxquels d'autres personnes sont liées sont assez bons sur le sujet, mais une autre ressource est le Security Review Module qui permet de s'assurer que tout est correctement configuré.

20
greggles

Je répondrai en considérant le 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 s'exécute (normalement, Apache s'exécute en tant que personne/personne). Cela signifie que l'utilisateur qui possède les fichiers créés manuellement avant d'exécuter le programme d'installation 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 correspondent). 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 Drupal, mais une fois l'installation terminée, il est suggéré de le rendre en lecture seule (le programme d'installation suggère que, et Drupal le fera périodiquement vérifier si le fichier est vraiment en lecture seule). Dans le scénario que je décris, l'autorisation de ce fichier devrait au moins être 644.
  • Les fichiers .htaccess (qui sont présents à au moins deux endroits) doivent avoir l'autorisation 644. L'utilisateur qui a créé le fichier doit toujours être en mesure d'écraser le fichier, dans le cas où une prochaine version de Drupal viendra avec un fichier .htaccess qui a été mis à jour (c'est déjà arrivé 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 répertoire default/files) Doit être (pour l'utilisateur affecté aux processus du serveur web, qui est alors l'utilisateur affecté au PHP scripts exécutés sur ce serveur Web):
    • lisible
    • accessible en écriture
    • traversable (les modules doivent pouvoir atteindre default/files/<directory-used-by-the-module>/<sub-directory-used-by-the-module>)
9
kiamlaluno

Autorisations de fichier/répertoire recommandées:

  • La racine Web Drupal doit être lisible par tout le monde (voir: pdater.inc ): 0755
  • pour les répertoires de téléchargement publics: 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 répertoires 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,
  • (facultativement) le groupe de toutes les sources doit être défini sur le groupe Apache,

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

file_chmod_directory: 0775
file_chmod_file: 0664

Voici un script pour corriger les 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 va essayer de récupérer le groupe Apache et le définir sur GET_HTTP_GROUP variable.

7
kenorb

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

Je l'exécute occasionnellement 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.
4
Richard Robinson

De plus, si vous exécutez fastcgi, le php s'exécute COMME l'utilisateur et aura accès à tous les fichiers auxquels l'utilisateur a accès, sauf si vous essayez délibérément d'éviter cela.

3
G.Martin

Cela m'a aidé avec mes problèmes de permission OSX. Je l'ai trouvé dans https://www.drupal.org/node/244924#comment-3741738 par l'utilisateur du protoplasme. J'étais comme lui ayant 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
1
cayerdis

Il existe un module appelé Security review qui vérifie si votre site est sécurisé ou non. J'ai également trouvé un très bon lien pour définir les autorisations du site.

0
Manikandan