Eu tenho um servidor multiusuário, que coloca um subconjunto dos usuários em um chroot. Quero permitir que todos os usuários liguem para passwd para alterar suas respectivas senhas. Tudo o mais que consigo pensar é exagerado ou susceptível de comprometer a segurança do sistema.
Eu construo meu chroot com makejail usando a seguinte configuração.
chroot="/var/chroot/sshd"
cleanJailFirst=1
# these are binds to the actual location, hence, we don't want makejail to be tinkering with those.
preserve=["/home","/etc/passwd","/etc/group","/srv"]
testCommandsInsideJail=["bash","sh","ls","pwd","stat","whoami","svnserve -t","locale","localedef","man ssh","man scp","cat","nano","vim","ssh","scp","passwd"]
testCommandsOutsideJail=[]
packages=["coreutils"]
# speed up things a bit
sleepAfterStartCommand=0.8
sleepAfterTest=0.8
Como você pode ver, em testCommandsInsideJail , eu listei passwd , mas se eu fizer login como meu testuser (que está dentro desse chroot), eu recebo:
$ passwd
Changing password for test.
(current) UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged
que eu não entendo, infelizmente (antes que você pergunte, sim, tenho certeza que a senha que eu digitei está correta). Eu encontrei alguns sites via g, que me ajudam tão pouco quanto a mensagem de erro real. No meu entender, estou perdendo algum módulo pam, mas não sei como adicioná-lo ao script python que constrói a cadeia.
Estou executando o Ubuntu Server 10.04.
EDITAR
Eu tenho o% real/etc/passwd ligado (via /etc/fstab ) ao local do chroot passwd, que está em /var/chroot/sshd/etc/passwd , então modificações dentro do chroot são vistas do lado de fora. Eu também fiz o mesmo com /etc/shadow , que por algum motivo eu esqueci antes. Então, ao invés de
preserve=["/home","/etc/passwd","/etc/group","/srv"]
Eu tenho agora
preserve=["/home","/etc/passwd","/etc/shadow","/etc/group","/srv"]
e uma ligação adicional:
# chroot binds
/home /var/chroot/sshd/home none bind 0 0
/etc/passwd /var/chroot/sshd/etc/passwd none bind 0 0
/etc/shadow /var/chroot/sshd/etc/shadow none bind 0 0
/etc/group /var/chroot/sshd/etc/group none bind 0 0
/srv /var/chroot/sshd/srv none bind 0 0
Se eu tentar alterar a senha agora, obtenho
$ passwd
Changing password for test.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged
Portanto, passwd consegue verificar a senha atual, mas morre quando se trata de configurá-la.
Mesmo se você passar para o chroot, será útil? O passwd dentro do chroot vai atualizar o / etc / passwd ou shadow no chroot, não o sistema passwd / shadow. Você provavelmente precisará nos dizer mais sobre o que exatamente você está servindo neste chroot, já que os detalhes podem nos ajudar a fornecer uma resposta melhor.
Você também precisa preservar as estruturas pam (geralmente /etc/pam.d)
Eu tive um problema semelhante, mas acredito que construí meu chroot de maneira diferente. Independentemente disso, como o host externo do chroot era um sistema Fedora Linux, eu tive que desabilitar o SELinux usando setenforce 0 antes que eu pudesse com sucesso chroot /path/to/chroot /bin/bash e então usar o passwd binário sem receber um "erro de manipulação do token de autenticação". / p>
Note que não tem nada a ver com senhas sombreadas vs não sombreadas (você deve sempre usar shadow), e eu estava tentando mudar a senha root dentro do chroot, então não tinha nada a ver com uma senha em branco, etc. / p>
strace na verdade me leva para o caminho errado nesse caso.
Além disso, parece ser específico do kernel, já que o 4.17.14 funcionava sem Desativando o SELinux, mas 4.17.9 exigia que eu fizesse isso.
De qualquer forma, nos sistemas CentOS, Redhat ou Fedora, com erros estranhos como esse, desligue o SELinux primeiro e veja se isso ajuda. Apenas certifique-se de ligá-lo novamente, está lá para ajudar.