Duas maneiras de bloquear uma senha, mas apenas uma para desbloquear

Question

O CentOS 6 Linux tem duas maneiras de bloquear uma senha:

1. passwd -l
2. usermod -L

Hoje descobri que eles fazem algo diferente.

passwd escreve dois pontos de exclamação no arquivo shadow.

# passwd -d test1
Removing password for user test1.
passwd: Success
# passwd -l test1
Locking password for user test1.
passwd: Success
# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)
# grep test1 /etc/shadow
test1:!!:16084:0:99999:7:::

Mas usermod escreve apenas um.

# passwd -d test1
Removing password for user test1.
passwd: Success
# usermod -L test1
# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)
# grep test1 /etc/shadow
test1:!:16084:0:99999:7:::

Isto é apenas uma inconsistência cosmética ou existe algum significado para os diferentes indicadores de bloqueio?

Coisas engraçadas acontecem, se você misturar os dois comandos:

Bloqueie uma conta com passwd :

# passwd -l test1
Locking password for user test1.
passwd: Success

Desbloqueie-o com usermod :

# usermod -U test1

E a surpresa ainda está bloqueada:

# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)

Bug ou recurso?

    

Answer 1

Não importa. O comportamento que você está vendo é específico da implementação . É por isso que usermod faz uma coisa e passwd faz outra coisa. Eles são implementações diferentes. Veja o que acontece no Solaris, AIX, HP-UX, True64, Xenix ...

O campo de senha é uma string criptografada ou em hash. Quando o usuário fornece uma senha, ela é criptografada ou hash de acordo com o algoritmo especificado no campo de senha. A autenticação só será bem-sucedida se os formulários crypted / hashed fornecidos e armazenados corresponderem.

Um único ! ou um duplo !! nunca pode corresponder a qualquer senha criptografada. Em outras palavras, não há nenhuma entrada que já tenha sido criptografada para o valor de resultado ! ou !! . Qualquer string que nunca poderia ser o resultado hash "bloqueará" a conta. Pode ser também foo ou Mr. Spock .

Observe também este comentário sob o sinal --lock em passwd(1) no Linux:

Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970).

    

Answer 2

Isso soa como um bug, mas provavelmente é completamente cosmético, contanto que você fique com uma ferramenta ou outra, mas não com as duas coisas! Se você der uma olhada na página man shadow ( man 5 shadow ), tem isto a dizer sobre o campo password (no CentOS).

   encrypted password
       Refer to crypt(3) for details on how this string is interpreted.

       If the password field contains some string that is not a valid result
       of crypt(3), for instance ! or *, the user will not be able to use a 
       unix password to log in (but the user may log in the system by other 
       means).

       This field may be empty, in which case no passwords are required to 
       authenticate as the specified login name. However, some applications 
       which read the /etc/shadow file may decide not to permit any access 
       at all if the password field is empty.

       A password field which starts with a exclamation mark means that the 
       password is locked. The remaining characters on the line represent 
       the password field before the password was locked.

Este último parágrafo faria o problema parecer que é um erro de implementação no comando passwd , já que um único ( ! ) é tudo o que é necessário para bloquear uma senha.

Indo mais a fundo

Uma coisa que me incomodou com a potencialidade acima de ser um bug é que não consigo imaginar que teria persistido por tanto tempo. A outra coisa que me incomodou é que no meu arquivo /etc/shadow eu tenho linhas como as seguintes:

abrt:!!:16047::::::
openvpn:!!:16047::::::
unbound:!!:16047::::::

Então, pesquisando um pouco mais, eu me deparei com este artigo intitulado: Noções básicas sobre arquivo / etc / shadow . Na seção de comentários deste artigo é o seguinte bit:

lesca September 23, 2010 at 4:29 am
!! means user account has not been initialed or has not been locked.
! means group password is not available.
* means login disabled.

Este último trecho movimentou minha memória o suficiente para lembrar que no passado não muito distante costumava haver senhas de grupo, bem como senhas de usuário. Você pode ler mais sobre eles neste post intitulado: Linux Set ou Change User Password bem como a funcionalidade substituída gpasswd neste post de blog intitulado: Uma senha de grupo no Linux .

De qualquer forma, acredito que você tenha encontrado um bug! O bug está no comando passwd .

    

Answer 3

Deixe-me explicar isso para você

A diferença é que o Linux tem duas maneiras de bloquear o login de um usuário:

1- bloqueando a senha

2- bloqueando o nome de usuário

Primeiro:

passwd -l test < isso bloqueará a senha do usuário.

passwd -u test < a senha bloqueada só pode ser desbloqueada por isso,                    significa que apenas o usuário pode fazer o login.

Segundo:

teste usermod-L < isso bloqueará o nome de usuário.

usermod -U test o nome de usuário bloqueado só pode ser desbloqueado por isso,                    significa que apenas o usuário pode fazer o login.

Nota:

você não pode desbloquear a senha de um usuário que  está bloqueado pelo utilitário " passwd " com o utilitário " usermod " e vice-versa.

    

Answer 4

"you can not unlock the password of a user which is locked by "passwd" utility with "usermod" utility and vice-versa."

Alguém postou informações acima ..

Não é verdade, a conta bloqueada usando o comando usermod pode ser desbloqueada usando o comando passwd -u .

A conta bloqueada usando o comando passwd -l pode ser desbloqueada usando o comando usermod -U (precisa ser executado duas vezes).