/bin/false
é um programa utilitário associado a /bin/true
, que é útil em algum sentido abstrato para garantir que o unix esteja completo de recursos. No entanto, propósitos emergentes para esses programas foram encontrados; considere a instrução BASH /some/program || /bin/true
, que sempre avalia booleana como true ( $? = 0
), independentemente do retorno de /some/program
.
Um uso emergente de /bin/false
, como você identificou, é como um shell nulo para usuários que não têm permissão para efetuar login. Nesse caso, o sistema se comportará exatamente como se o shell falhasse em executar.
POSIX (embora eu possa estar errado e o SUS) restrinja esses dois comandos a fazer exatamente nada além de retornar o valor booleano apropriado.
/sbin/nologin
é um utilitário BSD que possui um comportamento semelhante a /bin/false
(retorna boolean false), mas também imprime a saída, como /bin/false
é proibido. Isso deve ajudar o usuário a entender o que aconteceu, embora na prática muitos emuladores de terminal simplesmente fechem quando o shell terminar, tornando a mensagem praticamente ilegível em alguns casos.
Há pouca finalidade de listar /sbin/nologin
no /etc/shells
. O efeito padrão de /etc/shells
é listar os programas permitidos para uso chsh
quando os usuários estão alterando seu próprio shell (e não há motivo credível para mudar seu próprio shell /sbin/nologin
). O superusuário pode alterar o shell de qualquer um para qualquer coisa. No entanto, convém listar os itens " in" /sbin/nologin
e " /bin/false
in" /etc/rsh
, o que proibirá que os usuários com esses shells alterem seu shell usando chsh
no infeliz evento de obter um shell.
Os daemons de FTP podem proibir o acesso a usuários com um shell que não esteja no / etc / shells ou podem usar qualquer outra lógica que desejarem. A execução do FTP deve ser evitada em qualquer caso, porque sftp
(que fornece funcionalidade semelhante) é semelhante, mas seguro. Alguns sites usam /sbin/nologin
para desativar o acesso ao shell e, ao mesmo tempo, permitir o acesso sftp /etc/shells
. Isso pode abrir um backdoor se o usuário tiver permissão para criar cronjobs.
Em qualquer um dos casos, scp
não funcionará com um shell inválido. scponly
pode ser usado como um shell nesta instância.
Além disso, a escolha do shell afeta a operação do su -
(AKA su -l
). Particularmente, a saída de /sbin/nologin
será impressa em stdout se for o shell; não pode ser esse o caso /bin/false
. Em ambos os casos, os comandos executados com su -cl
falharão.
Finalmente, a resposta:
Para desabilitar uma conta, dependa de nenhuma dessas opções, mas defina o shell como /sbin/nologin
para fins informativos (a menos que /sbin/nologin
esteja dentro /etc/shells
, nesse momento você deve usar /bin/false
e não deveria estar). Em vez disso, defina o campo de senha /etc/passwd
como !
, o que é garantido crypt
como válido para nenhuma senha. Considere definir o hash /etc/shadow
da mesma maneira para evitar erros. passwd -l
fará isso por você.
Uma terceira maneira de desativar uma conta é definir o campo de data de validade da conta para uma data antiga (por exemplo, usermod --expiredate 1
). Isso impedirá logins, caso sua configuração permita que os usuários se autentiquem em sua conta unix sem uma senha e o serviço que eles estão usando não exija shell.