Calculer Girl
  1. Calculer Girl
  3. Configuration de la production standard pour PHP
Intereting Posts
2 installations identiques d’apache / php renvoient des résultats différents de la même firebase database SQL Server Erreur d’installation de Yeoman sur Ubuntu Redirection vers un autre domaine avec des parameters strptime dans les fenêtres? Comment configurer Unicorn sur Ubuntu? Réécriture des URL à l’aide de mod_rewrite Comment connaître le système d’exploitation utilisé par l’ordinateur cible par son IP à l’aide du script shell? Powershell: entrée de tuyau à la commande exécutée via l’opérateur d’appel convertir exponentielle en décimal en python Comment fermer automatiquement la boîte de dialog CameraCaptureDialog après avoir pris une photo en utilisant C # mise en évidence du texte dans listview à partir de la requête linq Comment puis-je déterminer la police “la plus étroite” sur Windows? Comment puis-je transférer un repository git sur un serveur distant via ssh? Comment gérer l’espace en valeur – Script Unix KSH règle de réécriture htaccess pour redirect le domaine à charger à partir d’un dossier sans montrer le nom du dossier dans l’url

Configuration de la production standard pour PHP

Contexte J’ai récemment installé un site basé sur php sur un hôte auquel j’ai un access root. J’ai installé une configuration de lampe basée sur les guides sur linode.com, et je me demande maintenant ce qu’il faut faire à propos des permissions de fichiers PHP, des permissions de répertoire et des utilisateurs qui doivent exécuter les processus dans quels groupes.

En particulier, j’aimerais une réponse à la question “Comment un site Web php standard devrait-il être configuré en ce qui concerne les ACL, les identifiants de propriété et de production?”

Actuellement, toute liste de répertoires renvoie les éléments suivants: 

-rw-r--r-- 1 root root 70 Nov 8 17:17 index.php

ie propriétaire root groupe root , mode 644 / uw & ar . ([edit] Ce qui n’est pas comme cela devrait être puisque les fichiers ne devraient pas être créés en utilisant root – une partie de la raison de cette question)

En ps -auxww je vois que le serveur Web Apache s’exécute en tant qu’utilisateur appelé www-data . Je peux donc supposer que php s’exécutera en tant que même utilisateur (probablement un processus enfant qui héritera du même utilisateur).

Serait-il faux pour moi de définir chmod 640 sur tous les fichiers et de me définir (utilisateur bob ) comme propriétaire, créer un groupe appelé productionIDs contenant l’utilisateur www-data , définir le groupe sur le fichier comme ID de productionIDs ?

Il me semble que cela serait plus sûr en termes de moindre privilège; Qui d’autre est-il autre que moi et le serveur web? Seulement je dois écrire les fichiers et le serveur Web doit seulement lire. Personne d’autre n’a besoin de faire quoi que ce soit.

Mon installation ne gère pas le cas où il y a plusieurs développeurs, mais je ne suis pas sûr de ce à quoi cette affaire devrait ressembler.

Y a-t-il des risques avec le propriétaire du groupe 640 , le groupe de serveurs Web du groupe? Si oui, le répertoire correspondant 750 également sécurisé?

Sinon, pourquoi pas plus de personnes utilisent cette configuration?

[mise à jour] Sous l’ essayer et voir la théorie, ça marche. La question comporte donc maintenant un aspect “qu’est-ce que cette configuration ne permet pas / quels sont les inconvénients de cette configuration”.

Tout d’abord, vos fichiers ne doivent absolument pas appartenir à root: root. Commencez avec un nom d’utilisateur et un groupe générique pour tous les propriétaires.

Bien qu’il soit initialement vrai que l’utilisateur du serveur Web n’aura besoin que d’un access en lecture / exécution à vos fichiers, il peut certainement avoir besoin d’un access en écriture à un dossier spécifique pour les téléchargements ou les journaux d’application.

Donc, notre configuration typique pour une application PHP est 644 sur les fichiers (640 convient également) et 755 pour les dossiers (750 fonctionneront également). Notez que nous laissons les fichiers lisibles par tout le monde pour plusieurs raisons. Tout d’abord, il permet aux autres utilisateurs d’auditer le code sur un serveur sans avoir la possibilité de le modifier. Deuxièmement, nous avons uniquement des utilisateurs de développeurs sur le serveur d’hébergement de production afin que toute personne disposant d’un compte dispose déjà du niveau de confiance pour afficher tout le code. Cette situation peut varier dans un autre contexte.

En ce qui concerne votre question sur l’utilisation du groupe de serveurs Web en tant que propriétaire du groupe, nous ne le faisons généralement pas. Bien que vous puissiez certainement utiliser ce groupe, nous souhaitons laisser seuls les groupes installés sur le système et créer un groupe spécifique pour les fichiers d’application. Ensuite, nous ajoutons simplement l’utilisateur du serveur Web au nouveau groupe.