/bin/false est un programme utilitaire, compagnon de /bin/true qui est utile dans un certain sens abstrait pour s'assurer qu'unix est complet en termes de fonctionnalités. Cependant, des objectifs émergents pour ces programmes ont été trouvés ; considérez l'instruction BASH /some/program || /bin/true qui donnera toujours la valeur booléenne "vrai" ( $? = 0 ), quel que soit le retour de /some/program .
Une utilisation émergente de /bin/false comme vous l'avez identifié, est un Shell nul pour les utilisateurs non autorisés à se connecter. Dans ce cas, le système se comportera exactement comme si le Shell avait échoué à s'exécuter.
POSIX (mais je peux me tromper et il se peut que ce soit le SUS) contraint ces deux commandes à ne rien faire d'autre que de retourner la valeur booléenne appropriée.
/sbin/nologin est un utilitaire BSD qui a un comportement similaire à celui de /bin/false (renvoie le booléen false), mais imprime aussi la sortie, comme /bin/false est interdit de faire. Ceci est censé aider l'utilisateur à comprendre ce qui s'est passé, bien qu'en pratique, de nombreux émulateurs de terminaux se ferment simplement lorsque le Shell se termine, rendant de toute façon le message quasiment illisible dans certains cas.
Il y a peu d'intérêt à énumérer /sbin/nologin en /etc/shells . L'effet standard de /etc/shells est de lister les programmes autorisés à être utilisés avec chsh lorsque les utilisateurs modifient leur propre Shell (et il n'y a aucune raison crédible de modifier son propre Shell pour /sbin/nologin ). Le superutilisateur peut changer le Shell de n'importe qui en n'importe quoi. Cependant, vous pouvez vouloir lister les deux /sbin/nologin y /bin/false en /etc/rsh qui interdira aux utilisateurs disposant de ces shells de modifier leur Shell à l'aide de chsh dans le cas malheureux où ils obtiennent un Shell.
Les démons FTP peuvent interdire l'accès aux utilisateurs dont le Shell ne figure pas dans /etc/shells, ou ils peuvent utiliser toute autre logique qu'ils souhaitent. L'exécution de FTP est à éviter dans tous les cas car sftp (qui offre une fonctionnalité similaire) est similaire mais sécurisé. Certains sites utilisent /sbin/nologin pour désactiver l'accès à Shell tout en autorisant l'accès à sftp en le mettant en /etc/shells . Cela peut ouvrir une porte dérobée si l'utilisateur est autorisé à créer des cronjobs.
Dans les deux cas, scp ne fonctionnera pas avec un Shell invalide. scponly peut être utilisé comme un Shell dans ce cas.
En outre, le choix de Shell affecte le fonctionnement de su - (AKA su -l ). En particulier, la sortie de /sbin/nologin sera imprimé sur stdout s'il s'agit du Shell ; ce qui ne peut être le cas avec /bin/false . Dans les deux cas, les commandes exécutées avec su -cl échouera.
Enfin, la réponse :
Pour désactiver un compte, ne dépendez d'aucun d'entre eux, mais définissez le Shell sur /sbin/nologin à des fins d'information (sauf si /sbin/nologin est en /etc/shells à ce moment-là, vous devez utiliser /bin/false ce qui ne devrait pas être le cas). Au lieu de cela, définissez le champ du mot de passe dans /etc/passwd a ! qui est garanti par crypt pour être valide pour aucun mot de passe. Envisagez de définir le hachage dans /etc/shadow de la même manière pour éviter les bugs. passwd -l le fera pour vous.
Une troisième façon de désactiver un compte est de définir le champ de la date d'expiration du compte sur une date ancienne (ex. usermod --expiredate 1 ). Cela empêchera les connexions dans le cas où votre configuration permet aux utilisateurs de s'authentifier contre leur compte unix sans mot de passe et que le service qu'ils utilisent ne nécessite pas de Shell.
