/ var / www propriétaire pour Apache2 et l'accès ftp
Apache2 est exécuté sur Ubuntu Server 12.04 LTS sur un ancien ordinateur portable. C'est sur mon réseau local d'agir en tant que serveur Web pour m'aider à apprendre PHP (et Linux).
Le propriétaire par défaut du dossier/var/www (où sont stockées les pages Web pour Apache) est www-data. Avec le propriétaire défini sur www-data, je ne peux pas copier de fichiers/dossiers dans ce dossier via ftp. Si je change le propriétaire du dossier/var/www en james (mon utilisateur FTP), je peux déplacer les fichiers via FTP, mais Apache n’a pas accès à l’affichage des pages ni des sous-dossiers.
Quel doit être le propriétaire correct pour autoriser l'accès aux utilisateurs ftp james et apache?
Je recommanderais de le définir comme appartenant à james:james.
Alternativement, vous pouvez le laisser sous la forme root:root et demander Sudo à quiconque y déploie des fichiers, mais si vous travaillez directement dans le répertoire/var/www (plutôt que de travailler ailleurs et d'y placer les fichiers) ) qui peut ne pas être pratique, et cela ne fonctionnera pas avec FTP non plus.
Vous pouvez définir le propriétaire de/var/www sur ce que vous voulez, à condition que l'utilisateur www-data ait un accès en lecture. Vous pouvez y parvenir en définissant des autorisations pour autoriser l'accès en lecture au monde (par défaut).
Par défaut, il appartient à root:root (not www-data comme vous le dites dans la question).
Pour la sécurité, c’est pas une bonne idée de le définir comme appartenant à
www-data.www-dataest destiné à être un compte non privilégié qui ne peut pas écrire dans des fichiers et ne peut que les lire.Oui, vous pouvez parfois avoir besoin de donner à
www-datal'autorisation d'écrire dans un fichier donné, mais pour des raisons de sécurité, limitez-vous à ces fichiers et veillez à prendre des précautions, par exemple en vous assurant qu'aucun fichier n'est exécutable. les scripts du serveur Web (c'est-à-dire qu'ils ne se trouvent pas à un emplacement où ils peuvent être interprétés comme des fichiers PHP ou CGI), etc.Pour la sécurité, il est même pire) de définir les autorisations de fichier sur les droits en écriture (par exemple, 777). Les utilisateurs non privilégiés tels que
www-datadevraient pas être en mesure d'écrire dans les fichiers de ce répertoire. Les seules personnes ayant besoin d'un accès en écriture seront celles qui écrivent des fichiers.Le répertoire/var/www est destiné à vous permettre de faire ce que vous aimez. Il est logique de définir la propriété sur le compte qui modifiera les fichiers. Vous pouvez créer un groupe à cet effet si vous avez plusieurs personnes, mais dans ce cas, c'est juste vous.
Remarque: si vous créez un groupe, créez un nouveau groupe. Faites not réutilisez le groupe
www-datacar il s'agit d'un groupe non privilégié sans accès en écriture à aucun fichier (comme je l'explique ci-dessus).
Trop souvent, je vois des gens qui recommandent d’adopter de très mauvaises pratiques de sécurité telles que définir/var/www comme appartenant à www-data ou ajouter des personnes au groupe www-data afin de donner les privilèges d’édition de ce groupe, ou la définition de/var/www pour être accessible en écriture (par exemple 777). En agissant de la sorte, vous vous exposez potentiellement à d'importants problèmes de sécurité.
La permission idéale est de vous définir en tant que propriétaire et en tant que groupe www-data, et de vous définir en tant que propriétaire des fichiers par Sudo chown -R yourname:www-data /var/www/public_html/ et Sudo chmod -R g+w /var/www/public_html/ en vous assurant de modifier le répertoire et le nom d'utilisateur de manière appropriée. Vous pourrez écrire des fichiers et les processus Apache ne seront pas gênés. Je suggère cela car l'OP exécute une instance locale d'Apache à des fins de formation et utilisera de nombreux scripts ou scripts opensource tels que wordpress, etc., qui nécessiteront un accès en écriture. Ici, la sécurité n’est pas une préoccupation majeure car le serveur local n’utilisera pas d’adresse IP publique et la facilité d’installation, de copie et d’exécution de scripts revêt une importance primordiale. Le PO peut se concentrer sur l’apprentissage de PHP plutôt que sur l’administration du serveur.