/bin/false
est un programme utilitaire, associé à /bin/true
, qui est utile dans un sens abstrait pour s'assurer que Unix est complet. Cependant, des objectifs émergents pour ces programmes ont été trouvés; considérons l'instruction BASH /some/program || /bin/true
, qui sera toujours booléenne-évaluer comme vraie ( $? = 0
), peu importe le retour de /some/program
.
/bin/false
Comme vous l'avez indiqué, une utilisation émergente correspond à un shell null pour les utilisateurs non autorisés à se connecter. Dans ce cas, le système se comportera exactement comme si l'exécution du shell avait échoué.
POSIX (bien que je puisse me tromper et qu'il se peut que le SUS) contraigne ces deux commandes à ne rien faire d’autre que de renvoyer la valeur booléenne appropriée.
/sbin/nologin
est un utilitaire BSD qui a un comportement similaire à /bin/false
(renvoie boolean false), mais affiche également la sortie, comme il /bin/false
est interdit de le faire. Ceci est supposé aider l'utilisateur à comprendre ce qui s'est passé, bien qu'en pratique, de nombreux émulateurs de terminal se ferment simplement lorsque le shell se termine, rendant le message presque illisible dans certains cas.
Il y a peu de but à la liste /sbin/nologin
en /etc/shells
. L’effet standard de /etc/shells
est de répertorier les programmes pouvant être utilisés chsh
lorsque les utilisateurs changent leur propre shell (et il n’existe aucune raison valable de changer votre propre shell en /sbin/nologin
). Le superutilisateur peut changer la coquille de n'importe qui. Cependant, vous voudrez peut-être lister les deux /sbin/nologin
et /bin/false
in /etc/rsh
, ce qui empêchera les utilisateurs de ces shells de changer de shell en utilisant, chsh
dans le cas malheureux, l'obtention d'un shell.
Les démons FTP peuvent interdire l'accès aux utilisateurs dont le shell n'est pas dans / etc / shells, ou utiliser toute autre logique de leur choix. L'exécution de FTP est à éviter dans tous les cas car sftp
(qui offre une fonctionnalité similaire) est similaire mais sécurisée. Certains sites utilisent /sbin/nologin
pour désactiver l' accès au shell tout en permettant un accès sftp en le mettant dans /etc/shells
. Cela peut ouvrir une porte dérobée si l'utilisateur est autorisé à créer des tâches cron.
Dans les deux cas, scp
ne fonctionnera pas avec un shell non valide. scponly
peut être utilisé comme un shell dans ce cas.
De plus, le choix du shell affecte le fonctionnement de su -
(AKA su -l
). En particulier, la sortie de /sbin/nologin
sera imprimée sur stdout s'il s'agit de la coque; cela ne peut pas être le cas avec /bin/false
. Dans les deux cas, les commandes exécutées avec su -cl
vont échouer.
Enfin, la réponse:
Pour désactiver un compte, ne dépendez d’aucun d’eux, mais définissez le shell sur /sbin/nologin
à des fins d’information (à moins qu’il ne /sbin/nologin
soit entré /etc/shells
, vous devez alors utiliser /bin/false
ce qui ne devrait pas être le cas). Au lieu de cela, définissez le champ de mot de passe /etc/passwd
pour !
, qui est garanti par crypt
être valable pour aucun mot de passe. Envisagez de définir le hachage de /etc/shadow
la même manière pour éviter les bugs. passwd -l
fera cela pour vous.
Un troisième moyen de désactiver un compte consiste à définir le champ de date d'expiration du compte sur une date ancienne (par exemple usermod --expiredate 1
). Cela empêchera les connexions si votre configuration permet aux utilisateurs de s'authentifier auprès de leur compte unix sans mot de passe et si le service utilisé ne nécessite pas de shell.