J'utilise Debian 7 et j'ai créé un nouvel utilisateur (site Web) avec un répertoire htdocs comme celui-ci :
$ sudo adduser website
$ sudo mkdir -p /home/website/htdocs
$ sudo chown -R website /home/website
Maintenant, j'aimerais que les utilisateurs d'un autre groupe (développeurs) aient accès au répertoire de l'utilisateur. J'ai essayé :
$ sudo chown -R :developers /home/website
Je peux voir que le groupe est assigné (avec ls -la ou stat ) et que les utilisateurs sont dans le groupe, mais ils n'ont pas le droit d'accès ?
drwxr-xr-x 3 website developers 4096 May 3 09:09 website
Je souhaite également :
-
Autoriser un autre groupe, les « sous-traitants », à accéder aux fichiers du site Web
-
Restreindre l'accès des utilisateurs du site Web à leurs répertoires personnels uniquement
-
Assurez-vous que les nouveaux fichiers du site Web héritent de ces autorisations
Devez-vous utiliser des listes de contrôle d'accès ? Ou existe-t-il un meilleur moyen de le faire (comme ne pas utiliser un utilisateur distinct pour chaque site) ?
Réponse acceptée :
Il est difficile de donner des commandes précises sans connaître le système d'exploitation ou la distribution ; et oui! ACL fonctionnerait, mais il existe également une méthode standard.
Il y a adduser et useradd , l'un d'entre eux sur votre distribution peut créer automatiquement le répertoire personnel de l'utilisateur. Si oui, alors le contenu de /etc/skel/ serait copié dans le répertoire personnel de l'utilisateur, les autorisations définies et peut-être que d'autres actions appropriées pourraient avoir lieu.
Il peut exister des groupes prédéfinis pour le partage, tels que "personnel" ; mais, si nous voulons créer notre propre groupe de partage, il n'y a rien de mal à cela. Alors, créez un nouveau groupe ou utilisez un groupe existant. Assurez-vous que les utilisateurs qui doivent être membres du groupe ont été définis comme tels avec usermod , moduser , ou vigr peut-être, selon le système d'exploitation. Chaque utilisateur actuellement connecté doit se déconnecter et se reconnecter pour devenir membre d'un nouveau groupe.
Créez un répertoire commun à tous les utilisateurs, tel que /home/share_directory/ ou tout autre répertoire qui convient le mieux à votre situation. Une bonne pratique pertinente consiste à ne pas utiliser un répertoire dans le répertoire personnel de n'importe quel utilisateur. Si personne, à l'exception du propriétaire et du groupe, ne doit pouvoir voir les fichiers dans le répertoire, changez les autorisations du répertoire en 0770. Si la lecture est correcte pour "d'autres", alors utilisez 0775. Le propriétaire du répertoire doit presque certainement être root.
chown root:group_name /home/share_directory/
Ensuite, changez le bit setuid.
chmod +s /home/share_directory/
Si aucun utilisateur ne doit pouvoir modifier le fichier d'un autre utilisateur, définissez également le stick bit.
chmod +t /home/share_directory/
Ces exemples définissent à la fois les bits setuid et sticky en utilisant la notation octale.
chmod 5775 /home/share_directory/
ou
chmod 5770 /home/share_directory/
Pour la question mise à jour, il semble que ACL soit le bon outil. La plupart des distributions Linux incluent maintenant le acl option dans les defaults option. Si votre distribution n'inclut pas le acl option par défaut, alors ce petit travail est nécessaire pour commencer à l'utiliser. Montez d'abord les systèmes de fichiers avec acl option dans /etc/fstab.
sudo vim /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,acl 0 1
Si nécessaire, remontez le système de fichiers :sudo mount -o remount,acl / . Créez ensuite un groupe auquel un utilisateur peut appartenir à cet effet. Vous devrez peut-être également installer les outils ACL :apt-get install acl .
sudo groupadd developers
sudo usermod -a -G developers $username
(Ou le groupe peut être des « sous-traitants ».) Un utilisateur actuellement connecté doit se déconnecter et se reconnecter pour devenir membre du nouveau groupe. Bien sûr, ne le faites pas si vous avez du contenu dans le répertoire /var/www que vous souhaitez conserver, mais juste pour illustrer sa configuration pour commencer :
sudo rm -rf /var/www
sudo mkdir -p /var/www/public
sudo chown -R root:developers /var/www/public
sudo chmod 0775 /var/www/public
sudo chmod g+s /var/www/public
sudo setfacl -d -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -d -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
Ci-dessus, la différence entre le setfacl commandes sont les suivantes :la première instance utilise le groupe par défaut (groupe propriétaire de l'annuaire) tandis que la seconde spécifie explicitement un groupe. Le -d switch établit le masque par défaut (-m ) pour tous les nouveaux objets du système de fichiers dans le répertoire. Pourtant, nous devons également exécuter à nouveau la commande sans le -d switch pour appliquer l'ACL au répertoire lui-même. Remplacez ensuite les références à "/var/www" par "/var/www/public" dans un fichier de configuration et rechargez.
sudo vim /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 reload
Si nous voulions restreindre la suppression et le renommage de tous sauf l'utilisateur qui a créé le fichier :sudo chmod +t /var/www/public . De cette façon, si nous voulons créer des répertoires pour les frameworks qui existent en dehors de la racine du document Apache ou peut-être créer des répertoires inscriptibles par le serveur, c'est toujours facile.
Répertoire des journaux en écriture Apache :
sudo mkdir /var/www/logs
sudo chgrp www-data /var/www/logs
sudo chmod 0770 /var/www/logs
Répertoire de la bibliothèque lisible par Apache :
sudo mkdir /var/www/lib
sudo chgrp www-data /var/www/logs
sudo chmod 0750 /var/www/logs
Un peu de "jeu" dans un répertoire qui n'a pas d'importance devrait vous aider à faire en sorte que cela corresponde à votre situation.
Sur les restrictions, j'utilise deux approches différentes :le shell, rssh , a été conçu pour fournir un accès SCP/SFTP mais pas d'accès SSH ; ou, pour limiter l'utilisation à un répertoire personnel, vous pouvez utiliser le sous-système internal-sftp, configuré dans /etc/ssh/sshd_config .
Subsystem sftp internal-sftp
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Créez un groupe nommé, par exemple, sftponly. Rendez les utilisateurs membres du groupe sftponly. Remplacez leurs répertoires personnels par / à cause du chroot. Le répertoire, /home/username, doit appartenir à root. Vous pouvez également définir le shell de l'utilisateur sur /bin/false pour empêcher l'accès SSH. Je suis surtout préoccupé par l'accès interactif, alors allez généralement avec le rssh chemin. (Ils ne peuvent écrire nulle part sauf là où j'ai défini la capacité d'écriture.)