Dans un environnement multi-utilisateur utilisant le serveur Ubuntu 14.04 comme lecteur partagé
Tous les utilisateurs se connectent via SFTP à l’aide de Filezilla/WinSCP et chrootent vers /home/company-folder/
Chaque utilisateur a également son propre dossier personnel sous /home/company-folder/users/
. Par exemple. /home/company-folder/users/username-1
, /home/company-folder/users/username-2
et ainsi de suite ...
Maintenant, username-1
peut voir les dossiers personnels des autres utilisateurs (/home/company-folder/users/username-2
, /home/company-folder/users/username-3
, etc.), il ne peut pas accéder aux autres dossiers utilisateur, mais il peut les voir listés.
La question est: que puis-je faire pour que les utilisateurs ne puissent pas voir le répertoire personnel de chacun sous /home/company-folder/users/
? Est-il possible dans Ubuntu-Linux de cacher des dossiers non lisibles?
Étant donné que dans un système comptant plus de 100 utilisateurs, il n’est pas pratique pour les utilisateurs de parcourir la liste complète des dossiers d’utilisateurs pour trouver leur dossier personnel.
En général non. Seule la permission des répertoires (de votre point de vue) parent détermine si son contenu peut être répertorié par un utilisateur particulier. Cela inclut les entrées de répertoire que cet utilisateur ne peut pas ouvrir/lire. Le mécanisme d'accès SSH/SFTP est identique à celui des outils locaux, car le serveur SSH/SFTP génère un sous-processus pour chaque session et modifie la propriété du sous-processus en faveur de l'utilisateur respectif, dès qu'ils sont authentifiés avec succès.
Prenons l'exemple suivant:
david@localhost:~$ ls -la /home
dr-xr-xr-x 1 root root 80 Nov 10 09:05 .
drwxr-xr-x 23 root root 4,0K Dec 17 11:09 ..
drwxr-xr-x 1 guest guest 836 Sep 4 20:58 guest
drwxr-x--- 1 david users 4,2K Dec 14 22:07 david
drwx------ 1 root root 614 Nov 10 12:42 root
Comme vous pouvez le constater, je, david
, peux lister le contenu de /home
même si je ne suis pas son propriétaire, car tout le monde peut le lire (voir le masque de permission devant le .
entrée). Je peux lister le contenu de /home/guest
pour la même raison. Je peux aussi lister le contenu de /home/david
, puisque j'en suis le propriétaire et que celui-ci a la permission de lire. Cependant, je ne peux pas lister le contenu de /home/root
, car je ne suis pas le propriétaire et personne d'autre que le propriétaire n'a les autorisations de lecture sur ce répertoire:
david@localhost:~$ ls /home/root
ls: cannot open directory /home/root: Permission denied
Si on modifiait la propriété de /home
pour supprimer les droits de lecture des non-propriétaires, je ne pouvais plus répertorier le contenu de /home
:
david@localhost:~$ Sudo chmod o-r /home
david@localhost:~$ ls -ld /home
drwxr-x--x 2 root root 40 Dez 17 21:17 /home
david@localhost:~$ ls -l /home
ls: cannot open directory /home: Permission denied
Bien que je puisse toujours parcourir /home
et lire /home/david
, car l’autorisation de traversée (c’est la sémantique du bit "exécuter" sur les répertoires) est toujours définie sur /home
(et /
):
david@localhost:~$ ls -l /home/david
total 732K
drwx------ 1 david users 4,2K Dec 14 22:07 .
dr-xr-x--x 1 root root 80 Nov 10 09:05 ..
drwx------ 1 david users 60 Aug 24 2014 .Adobe
-rw------- 1 david users 83 Dec 6 19:49 .bash_aliases
-rw------- 1 david users 66 May 12 2011 .bash_completion
-rw------- 1 david users 703 Nov 23 05:41 .bash_exports
[etc...]
Voir réponse de Jakuje pour une autre approche possible de votre objectif sous-jacent.
Je ne sais pas comment faire ce que vous décrivez, mais il y a l'option -d
pour openssh sftp-server
, qui spécifie le répertoire de démarrage des utilisateurs, ce qui peut résoudre votre problème
[...] parcourir la liste complète des dossiers de l'utilisateur pour trouver son dossier personnel.
Si vous spécifiez votre sftp-server
tel que:
Subsystem sftp internal-sftp -d /users/%u
(vous devez omettre /home/company-folder/
, car vous y êtes déjà en train d’être chrooté).