Solution 1 :
Après plus de recherches, il semble qu'une autre (peut-être une meilleure façon) de répondre à cette question serait de configurer le dossier www comme ceci.
sudo usermod -a -G developer user1(ajoutez chaque utilisateur au groupe de développeurs)sudo chgrp -R developer /var/www/site.com/afin que les développeurs puissent y travaillersudo chmod -R 2774 /var/www/site.com/afin que seuls les développeurs puissent créer/modifier des fichiers (autre/monde peut lire)sudo chgrp -R www-data /var/www/site.com/uploadsafin que www-data (apache/nginx) puisse créer des téléchargements.
Depuis git s'exécute sous n'importe quel utilisateur qui l'appelle, alors tant que l'utilisateur est dans le groupe "développeur", il devrait pouvoir créer des dossiers, modifier des fichiers PHP et gérer le référentiel git.
Remarque :à l'étape (3) :'2' dans 2774 signifie 'définir l'ID de groupe' pour le répertoire. Cela fait que les nouveaux fichiers et sous-répertoires créés en son sein héritent de l'ID de groupe du répertoire parent (au lieu du groupe principal de l'utilisateur) Référence :http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
Solution 2 :
Je ne sais pas si c'est "juste", mais voici ce que je fais sur mon serveur :
- /var/www contient un dossier pour chaque site Web.
- Chaque site Web a un propriétaire désigné, qui est défini comme propriétaire de tous les fichiers et dossiers du répertoire du site Web.
- Tous les utilisateurs qui gèrent le site Web sont placés dans un groupe pour le site Web.
- Ce groupe est défini en tant que groupe propriétaire de tous les fichiers et dossiers du répertoire.
- Tous les fichiers ou dossiers qui doivent être écrits par le serveur Web (c'est-à-dire PHP) ont leur propriétaire modifié en www-data, l'utilisateur sous lequel apache s'exécute.
Gardez à l'esprit que vous devez activer le bit d'exécution sur les répertoires afin de pouvoir répertorier le contenu.
Solution 3 :
Après avoir fait plus de recherches, il semble que git/svn TOOLS ne sont PAS un problème puisqu'ils s'exécutent comme n'importe quel utilisateur qui les utilise. (Cependant, les démons git/svn sont une autre affaire !) Tout ce que j'ai créé/cloné avec git avait mes autorisations et l'outil git était répertorié dans /usr/bin qui correspond à cette thèse.
Permissions Git résolues.
Les autorisations des utilisateurs semblent pouvoir être résolues en ajoutant tous les utilisateurs qui ont besoin d'accéder au répertoire www au www-data groupe sous lequel apache (et nginx) s'exécutent.
Il semble donc qu'une seule réponse à cette question va comme ceci :
Par défaut /var/www appartient à root:root et personne pouvez y ajouter ou modifier des fichiers.
1) Changer le propriétaire du groupe
Nous devons d'abord changer le groupe de répertoires www pour qu'il appartienne à "www-data" au lieu du groupe "root"
sudo chgrp -R www-data /var/www
2) Ajouter des utilisateurs à www-data
Ensuite, nous devons ajouter l'utilisateur actuel (et toute autre personne) au groupe www-data
sudo usermod -a -G www-data demousername
3) Répertoire CHMOD www
Modifiez les autorisations afin que SEULS le propriétaire (root) et tous les utilisateurs du groupe "www-data" puissent rwx (lire/écrire/exécuter) les fichiers et répertoires (personne d'autre ne devrait même pouvoir y accéder ).
sudo chmod -R 2770 /var/www
Désormais, tous les fichiers et répertoires créés par tout utilisateur ayant accès (c'est-à-dire dans le groupe "www-data") seront lisibles/inscriptibles par apache et donc php.
Est-ce correct? Qu'en est-il des fichiers créés par PHP/Ruby ? Les utilisateurs de www-data peuvent-ils y accéder ?
Solution 4 :
L'adhérence n'est pas l'héritage des autorisations. L'adhérence sur un répertoire signifie que seul le propriétaire d'un fichier, ou le propriétaire du répertoire, peut renommer ou supprimer ce fichier dans le répertoire, malgré les autorisations indiquant le contraire. Ainsi 1777 sur /tmp/.
Dans Unix classique, il n'y a pas d'héritage d'autorisations basé sur le système de fichiers, uniquement sur umask du processus en cours. Sur *BSD ou Linux avec setgid sur le répertoire, le champ de groupe des fichiers nouvellement créés sera défini sur le même que celui du répertoire parent. Pour plus d'informations, vous devez examiner les ACL, avec l'ACL "par défaut" sur les répertoires, qui vous permettent d'hériter des autorisations.
Vous devez commencer par définir :* quels utilisateurs ont accès au système* quel est votre modèle de menace
Par exemple, si vous faites de l'hébergement Web avec plusieurs clients et que vous ne voulez pas qu'ils voient les fichiers les uns des autres, vous pouvez utiliser un groupe commun "webcusts" pour tous ces utilisateurs et un mode répertoire de 0705. Ensuite, les fichiers servis par le processus du serveur Web (pas dans "webcusts") verra les autres perms et sera autorisé ; les clients ne peuvent pas voir les fichiers des autres et les utilisateurs peuvent jouer avec leurs propres fichiers. Cependant, cela signifie qu'au moment où vous autorisez CGI ou PHP, vous avez pour s'assurer que les processus s'exécutent en tant qu'utilisateur spécifique (bonne pratique de toute façon, pour plusieurs utilisateurs sur un hôte, pour la responsabilité). Sinon, les clients pourraient jouer avec les fichiers des autres en demandant à un CGI de le faire.
Cependant, si l'utilisateur d'exécution d'un site Web est le même que le propriétaire du site Web, vous rencontrez des problèmes pour ne pas pouvoir protéger le contenu des abus en cas de faille de sécurité dans le script. C'est là que les hôtes dédiés gagnent, de sorte que vous pouvez avoir un utilisateur d'exécution distinct du propriétaire du contenu statique et ne pas avoir à vous soucier autant de l'interaction avec les autres utilisateurs.
Solution 5 :
Je pense que la meilleure façon d'y parvenir est d'utiliser les listes de contrôle d'accès Posix. Elles sont agréables à utiliser et offrent toutes les fonctionnalités dont vous avez besoin.
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs