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.

Verbetes relacionados

Como isso aparece dentro do Atlas?

Ir para a página do produto