Posso desbloquear a sessão gráfica de qualquer usuário sem saber sua senha se eu for root, apenas usando loginctl unlock-session <session>
.
Mas posso iniciar uma sessão gráfica como um usuário de alguma forma, sem saber sua senha? Posso fazer backup /etc/shadow
, alterar a senha, fazer login e restaurar, mas isso é muito trabalhoso, deve haver uma maneira melhor... Para o terminal/console, tenho o bom e velho sudo -i -u <user>
, que não precisa disso, talvez eu possa fazer algo assim para o ambiente gráfico também?
É totalmente legítimo no meu caso de uso. É sddm e desktop KDE/Plasma, se for importante.
Solução com PAM e uma única senha mestra
Se o seu sddm usa PAM, você pode modificá-lo
/etc/pam.d/sddm
e fazê-lo aceitar sua senha mestra para qualquer usuário.Criaremos um script auxiliar que comparará a primeira linha do stdin com sua senha mestra armazenada literalmente como a primeira linha em um arquivo separado.
Execute o código exato acima em um shell, ele criará os arquivos necessários. Em seguida
sudoedit /etc/security/master_password
, substituaM4st3rPSSwrd
pela sua senha mestra. (Substituir antes de executar o código pode quebrar as coisas se sua senha mestra contiver'
.) A senha mestra no arquivo deve ser terminada corretamente com um caractere de nova linha.sudoedit /etc/pam.d/sddm
e coloque as seguintes linhas antes de qualquerauth …
linha existente:A linha fará o sddm executar
master_password_check
e passar a senha digitada por meio de seu stdin. O script a comparará com a senha mestre e permitirá acesso imediatamente se elas corresponderem. A capacidade de efetuar login usando a senha regular do usuário alvo não é afetada.A partir de agora você pode efetuar login no sddm como qualquer usuário, bastando fornecer sua senha mestra.
Notas
auth sufficient …
linha fosse adicionada/etc/pam.d/common-auth
, muitos programas (incluindo o sddm) começariam a aceitar a senha mestra (porque os arquivos de configuração do PAM geralmente usam@include common-auth
quando apropriado)./etc/security/master_password
, ela é protegida apenas pelo modo do arquivo. Se isso não for suficiente para você, implemente o suporte para senha mestra com hash por conta própria./etc/pam.d/sddm
;Solução com PAM, política configurada em
sudoers
Crie
/usr/local/bin/use-own-password
com a propriedade e permissões corretas. O seguinte código shell fará isso:Sim, o arquivo deve ser executável para todos. O script por si só é totalmente inofensivo. Sua capacidade de logar um usuário como outro vem de sua interação com o PAM, quando ele é executado de dentro do PAM.
Em seguida
sudoedit /etc/pam.d/sddm
, coloque as seguintes linhas antes de qualquer linha existenteauth …
:Em seguida, execute
sudo visudo
e configure o sudoers:A solução não funcionará com
requiretty
. Em caso de dúvida, useDefaults !requiretty
.A solução aninha
sudo
s. O outersudo
será executado pelo root para executar o inner sudo como o usuário cujas credenciais você deseja usar. É crucial que o outersudo
não peça senha. Felizmente, esse é o caso: o root pode usarsudo
livremente e não acho que haja nem uma maneira de quebrar isso.Se e somente se o usuárioA for um sudoer com permissão para executar
/usr/local/bin/use-own-password no-op
como usuárioB, então nosso script autorizará o login no sddm como usuárioB com as credenciais do usuárioA fornecidas comouserA:passwordA
no campo de senha. Agora é seu trabalho configurar os sudoers, para que somente os usuários certos possam executar o script como usuários certos. As linhas básicas nosudoers
arquivo serão como:Usar
NOPASSWD
for permitirá que qualquer um faça login no sddm como userB apenas alegando que é userA (e usando qualquer senha). O ponto é que você ainda não está logado, em particular não está logado como userA e não há como verificar se você é userA, exceto a senha do userA. O sddm apenas passaráuserA:whatever
do campo de senha para o nosso script e, nesse caso,NOPASSWD
sempre terá sucesso.Tenha em mente que a última correspondência é usada . Por exemplo, você pode querer usar a linha de exemplo acima para
use-own-password
e genéricouserA ALL=(userB) NOPASSWD: ALL
para todo o resto; então você deve colocar a linha de exemplo após a linha genérica, caso contrário,NOPASSWD
da linha genérica será aplicada a sddm. Eu acho que você deve colocar todas as linhas permitindouse-own-password
bem no final desudoers
(mesmo depois de@includedir
e assim).Também tenha em mente que você não precisa de linhas específicas mencionando
use-own-password
para que a solução funcione. Uma linha genéricauserC ALL=(userD) ALL
permitirá que o userC faça login no sddm como userD. Se você quiser evitar especificamente isso, então você precisa transformar o últimoALL
em!/usr/local/bin/use-own-password
.Note que há opções (
rootpw
,targetpw
,runaspw
) que fazemsudo
a solicitação de senha diferente daquela de invocação do usuário. Elas interferirão, se usadas.Se você configurar tudo corretamente, você poderá logar no sddm como userB escolhendo userB como usuário e fornecendo
userA:passwordA
como senha. Os dois pontos são verbatim, é um separador.Como funciona
Nosso
use-own-password
tem dois modos de operação, eles são escolhidos pelo primeiro argumento.Primeiro, o PAM executa o script no
verify
modo, fornecendo a senha digitada (esperançosamenteuserA:passwordA
) via stdin. O script extrai o nome do usuário autenticador e sua senha real da string de senha.Então o script usa
sudo
para executar outrosudo
como o usuário autenticador, apenas para executar outra instância de si mesmo como o usuário alvo. A outra instância está nono-op
modo, onde é equivalente atrue
, seu único propósito é verificar se o usuário autenticador tem permissão (porsudoers
) para executar o script como o usuário alvo: o script terá sucesso se sim,sudo
falhará em primeiro lugar se não.O inner
sudo
lê a senha do seu stdin. É a senha extraída deuserA:passwordA
.Notas
userA:passwordA
são um separador. Nomes de usuários não podem conter:
, então não há ambiguidade sobre qual dois pontos é o separador.userX:passwordX
first. Pode acontecer que a senha do usuário alvo contenha:
; isso não quebrará as coisas porque se nosso script falhar, ele/etc/pam.d/sddm
continuará como se nada tivesse acontecido e eventualmente fará o login do usuário alvo (se a senha inteira estiver correta).userA:passwordA
, ondepasswordA
é a senha do usuárioA e esse usuário é um sudoer com acesso à nossa solução. Se for assim, então o usuário original, ao fornecer sua senha, inadvertidamente fará login usando nosso método e as credenciais do usuárioA. Em muitos casos não haverá diferença, pois ele ou ela faria login de qualquer maneira. Somente se/etc/pam.d/sddm
normalmente não permitiria o usuário original ou faria algo extra (por exemplo, exigir autenticação de dois fatores), então o usuário notará./etc/pam.d/sddm
vez de uma. Isso significa que no contexto da sua pergunta você, como administrador, pode ter controle granular sobre outros usuários (por meio desudoers
), enquanto usa uma senha mestra conveniente para seu próprio propósito./etc/pam.d/sddm
;/etc/sudoers
.