Tirei o acesso e a pessoa continua dentro: sessão não é a mesma coisa que permissão
Você tirou a permissão, até desativou a conta, e a pessoa ainda consegue fazer coisas. Nada quebrou: tirar o acesso e encerrar a sessão são duas ações diferentes.
AtlasPVE ·
Este verbete responde a
- proxmox apaguei o usuário e ele ainda entra
- proxmox tirei a permissão e ainda tem acesso
- proxmox desconecta o tempo todo
- quanto tempo dura uma sessão do proxmox
- proxmox revogar token de api
Você tirou a permissão de um usuário. Talvez tenha desativado a conta inteira. Depois percebe que aquela pessoa ainda consegue fazer coisas.
Nada quebrou. Entrar e estar autorizado são dois momentos diferentes, e entre eles existe uma folga.
A entrada acontece uma vez, a permissão é perguntada toda vez
Quando você entra, o sistema te entrega um bilhete. O bilhete diz: esta pessoa provou quem é, e este bilhete vale até tal hora.
A permissão é uma pergunta à parte, refeita a cada pedido. Mas na prática muitos sistemas tiram, no momento da entrada, uma cópia do mapa de permissões, por velocidade, e usam essa cópia por um tempo.
Daí nascem dois atrasos.
O primeiro: quando você tira uma permissão, uma sessão aberta pode continuar carregando aquela cópia. A mudança só a alcança quando a sessão se renova.
O segundo, e mais importante: apagar ou desativar o usuário não rasga o bilhete que ele tem na mão. O bilhete se basta e continua válido até vencer.
A regra: tirar o acesso não é encerrar a sessão
São duas ações diferentes, e fazer só a primeira deixa uma janela aberta atrás de você.
A janela não é infinita; um bilhete não vale um dia inteiro. Mas também não é zero, e numa situação urgente "vai fechar daqui a pouco" não é resposta suficiente.
Quando alguém sai, ou uma senha é suspeita
Faça três coisas, nesta ordem.
Tire a permissão. Desative também a conta, se for o caso.
Troque a senha. Isso fecha o caminho para conseguir um bilhete novo no lugar do que ele tem. Só tirar a permissão não faz isso.
Remova os tokens de acesso à parte. Esse é o passo mais pulado. Um token não é uma sessão: ele não vence sozinho, vive até você apagá-lo. Trocar a senha de um usuário não invalida os tokens dele. Ao remover um usuário, verifique à parte o que aconteceu com os tokens.
E vamos encerrar um equívoco: a verificação em duas etapas não te ajuda aqui. Ela protege o momento da entrada. Sobre uma sessão já aberta ela não tem nada a dizer.
O sentido contrário: por que ele me desconecta toda hora
É a outra face do mesmo mecanismo.
O bilhete tem vida limitada, e a interface o renova regularmente enquanto você está na aba. Feche a aba e volte horas depois: nenhuma renovação aconteceu, o bilhete morreu, e pedem para você entrar de novo. Isso não é defeito.
A segunda causa, menos conhecida, é mais interessante: o relógio da máquina. Um bilhete carrega uma marca de tempo. Se o relógio do servidor sai do lugar, um bilhete recém-emitido pode parecer vir do futuro ou estar vencido há muito. O sintoma confunde: a senha está certa, a entrada parece aceita, e logo em seguida a sessão cai. Procurar um problema de relógio do lado da identidade não passa pela cabeça de ninguém, mas procure.
O que o Atlas faz
No Atlas, o cookie que vai para o navegador não é o bilhete de verdade. O navegador carrega apenas um identificador aleatório sem significado; o bilhete real fica no servidor.
A diferença é concreta: mesmo que uma falha do navegador leia o cookie, ela não sai de lá com o bilhete em si, então não pode levá-lo para outro lugar e usá-lo lá. A única coisa que consegue é agir a partir daquele navegador enquanto aquela sessão viver. Não é risco zero, mas estreita o alcance da ameaça.
As sessões abertas são gravadas em disco, então ninguém é expulso quando o produto se atualiza. A gravação é feita de propósito em um único passo: se o arquivo tivesse ficado escrito pela metade, então, mesmo que o lado que lê tolere isso, todas as sessões abertas teriam caído.
O que de fato vale contar é um defeito encontrado aqui medindo.
Os registros de sessão vencidos eram limpos só da memória, não do arquivo. Uma máquina em serviço foi olhada: no arquivo havia cinco registros vencidos, cada um com um bilhete dentro. Eles teriam ficado ali até a próxima entrada, porque nada mais escrevia naquele arquivo.
A intenção do código já era não guardá-los. A única coisa que faltava era o passo de gravação.
A lição vale para quem escreve código de segurança: esquecer tem dois lugares. O que foi tirado da memória não foi tirado do disco, e dos dois o do disco sempre vive mais. Quando você decide que algo não deve ser guardado, a segunda pergunta é sempre a mesma: onde está guardado?
Fontes
A documentação oficial do Proxmox. Em inglês, e é ela que dá a palavra final neste assunto.