Comment empêcher les utilisateurs d'accéder à autre chose qu'à leur propre répertoire personnel?

22

Par exemple, j'ai une partition NTFS montée sous /media/ntfs, donc si l'utilisateur se connecte via ssh, il peut accéder à cette partition. Comment désactiver les utilisateurs pour cdsortir de leur répertoire personnel?

permissions users

— OH LA LA
source

22

Réévaluez d'abord votre besoin. Quel est le problème que vous essayez de résoudre? Pourquoi voulez-vous empêcher les utilisateurs de quitter leur répertoire personnel? N'est-ce pas plutôt que vous ne voulez pas qu'ils fouillent dans d' autres répertoires spécifiques - tels que les répertoires personnels d'autres utilisateurs?

Il est très difficile d'empêcher les utilisateurs de quitter leur répertoire personnel. C'est en fait un peu idiot aussi (l'explication suit). Il est beaucoup plus simple d'empêcher les utilisateurs d'entrer dans des répertoires que vous ne voulez pas qu'ils entrent.

Tout d'abord, oui, vous pouvez donner aux utilisateurs un soi-disant shell restreint , voir man rbash. Cela les empêchera de cdsortir ailleurs, mais uniquement à l'intérieur de cette coquille. Si l'utilisateur démarre viou nano(ou tout autre programme capable d'ouvrir un fichier), il peut à nouveau ouvrir des fichiers n'importe où sur le système. En fait, un shell restreint n'empêche pas par exemple cat /etc/passwd.

La prochaine étape est une prison racine. Plus d'informations sur le wiki de la communauté et dans cette question . Bien qu'une prison racine verrouille les utilisateurs dans un jardin clos, dans lequel ils n'ont accès qu'à des fichiers et des commandes que vous y avez intentionnellement placés, les prisons racine sont vraiment destinées à isoler les logiciels non fiables plutôt que les utilisateurs. En particulier, ils sont destinés aux logiciels qui doivent s'exécuter avec des privilèges élevés - d'où une prison racine .

Les utilisateurs, en revanche, sont fiables : ils ont dû s'authentifier et s'exécuter sans privilèges élevés. Par conséquent, les autorisations de fichiers suffisent pour les empêcher de modifier des fichiers dont ils ne sont pas propriétaires et de voir des choses qu'ils ne doivent pas voir. Pour empêcher les utilisateurs de lire le contenu d'un fichier, supprimez sa lisibilité universelle avec chmod o-r FILE. Pour garder les utilisateurs hors d'un répertoire, rendez-le inaccessible avec chmod o-rwx DIR.

La lisibilité mondiale est la valeur par défaut, pour une bonne raison: les utilisateurs ont en fait besoin de la plupart des éléments du système de fichiers. Ne verrouillez pas les utilisateurs chez eux simplement parce qu'il existe des secrets à l'extérieur.

Pourquoi verrouiller les utilisateurs dans leur répertoire personnel est un peu idiot

Pour faire quoi que ce soit d'utile, les utilisateurs doivent avoir accès aux commandes et aux applications. Ceux-ci se trouvent dans des répertoires comme /binet /usr/bin, donc à moins que vous ne copiiez toutes les commandes dont ils ont besoin à partir de là dans leurs répertoires personnels, les utilisateurs auront besoin d'accéder à /binet /usr/bin. Mais ce n'est que le début. Les applications ont besoin de bibliothèques à partir de /usr/libet /libqui, à leur tour, ont besoin d'accéder aux ressources système, qui se trouvent dans /dev, et aux fichiers de configuration dans /etcet /usr/share.

Ce n'était que la partie en lecture seule. Les applications voudront également /tmpet souvent /varécrire. Donc, si vous souhaitez contraindre un utilisateur dans son répertoire personnel, vous devrez en copier beaucoup. En fait, à peu près tout un système de fichiers de base - que vous avez déjà, situé à /.

— zwets
source

2

Cela n'a pas de sens pour moi, il pourrait y avoir tellement de raisons pour lesquelles vous voudriez qu'un utilisateur n'ait accès qu'à 1 dossier. Un exemple pourrait être de donner l'accès pour transmettre des fichiers d'un serveur à un autre. Je pense plutôt que c'est un peu idiot que n'importe quel utilisateur puisse parcourir le système complet à la place.

— Richard

Dans mon cas, je configure un utilisateur pour autoriser les périphériques à inverser ssh dans la machine pour la gestion à distance des périphériques. Je veux donc limiter ce compte d'utilisateur autant que possible au cas où il serait compromis - j'ai juste besoin que la connexion réussie soit établie. Je ne dirais pas que c'est idiot, cela dépend juste de ce que vous essayez d'accomplir.

— John

7

Je avais besoin de fournir un accès à l' utilisateur samsur /var/xyzseulement et contenu liste des blocs d'autres dossiers à l' intérieur/var/

J'ai utilisé la séquence de commandes suivante:

setfacl -R -m user:sam:--- /var/

setfacl -m user:sam:rx /var/

setfacl -R -m user:sam:rwx /var/xyz/

Ainsi, l'utilisateur peut voir les répertoires répertoriés sous /var/mais ne peut pas voir le contenu des sous-répertoires sauf /var/xyz.

— Sam
source

2

Bienvenue sur askubuntu! Je ne vois pas cela comme une réponse à la question posée concernant les répertoires personnels.

— Elder Geek

3

@ElderGeek L'OP ne peut-il pas simplement utiliser les mêmes commandes, mais pour le répertoire personnel?

— Seth

@Seth Oui, mais cela serait-il clair pour l'utilisateur moyen?

— Elder Geek

3

@ Elder Oui, je pense que oui. Pas parfait, mais toujours une réponse

— Seth

1

En plus de restreindre l'accès aux autres répertoires, en particulier les répertoires personnels des autres utilisateurs, je ne voulais pas non plus qu'un utilisateur puisse ll /homevoir les noms des autres utilisateurs du système.

Pour éviter cela, en tant qu'utilisateur root chmod 701 /home. Cela rend le /homerépertoire lui-même "lecture / écriture / exécution" à la racine bien sûr, mais seulement "exécuter" à tout le monde. /homeest toujours accessible à cd, mais les utilisateurs ne peuvent pas lire son contenu - les dossiers de départ des autres utilisateurs et donc les noms d'utilisateur.

— Willman
source

Ceci, bien que n'étant pas strictement une réponse à la question, est toujours très intéressant ... Dans une situation où vous utilisez un serveur distant auquel les clients peuvent accéder, c'est très bien. Ils peuvent toujours se déplacer comme ils le souhaitent, tout en conservant la confidentialité des noms d'utilisateur des autres clients.

— Jack_Hu