/ dev / shm / ecryptfs- $ USER-Private continua subindo no Kubuntu 12.10 Instalar

1

Estou tendo um problema com uma instalação do Kubuntu 12.10 com um diretório pessoal criptografado. Eu tenho tentado descobrir isso por várias semanas. Para a transparência, vou observar aqui que eu postei essa pergunta no askubuntu.com por um tempo, mas desci de lá e postei aqui, em vez disso, por causa da falta de resposta.

Eu percebi algumas semanas atrás que quando eu me desconectava do meu sistema, meu diretório pessoal criptografado nem sempre era re-criptografado - eu ainda era capaz de ver e acessar os arquivos dentro do diretório home quando eu usava o SSH. computador de outro computador (para ficar claro, meu SSHD requer uma chave compartilhada - isso pode ser relevante mais tarde). Fiz algumas leituras e descobri que ecryptfs depende de um arquivo de contador em /dev/shm/ecryptfs-$USER-Private para saber quando criptografar novamente o diretório inicial: quando um usuário está logado, o contador é '1' e quando o usuário efetua logout, o contador atinge '0' e aciona a criptografia.

Rodando cat /dev/shm/ecryptfs-my_user_name-Private periodicamente, achei algo estranho: o arquivo do contador permanece em 1 por um tempo depois que eu efetuo login na máquina física e depois começa a crescer. Em um ponto, depois de deixar o sistema ligado por vários dias, foi (como eu me lembro) em 93!

Encontrei um relatório sobre o mesmo tipo de problema no link . Essa página afirmou que coisas diferentes podem causar aumentos no contador, incluindo ssh logins e cron .

Mesmo depois de ler essa página, estou com muitos problemas para descobrir o que está causando o problema. Aqui estão algumas coisas que eu observei:

1) Embora o contador seja redefinido para 1 quando eu reinicio meu computador e, em seguida, efetuo login novamente, o contador ainda começa a aumentar após várias horas depois que eu estou conectado.

2) Isso acontece mesmo quando não tenho conexões SSH ativas para o meu computador.

3) Isso acontece mesmo quando meu computador está em redes diferentes. Assim, não acho que tenha a ver com um usuário não autorizado que tenha acesso ao meu sistema.

4) Isso não parece fazer com o uso de sudo no terminal (ou o equivalente em uma GUI).

5) Eu configurei um cron job para gravar a saída de cat /dev/shm/ecryptfs-my_user_name-Private a cada 5 minutos, e não consegui encontrar nenhuma correlação entre qualquer coisa que eu estava fazendo no momento e o ponto em que o contador começou a aumentar (para começar, de 1 a 3).

6) Eu também desabilitei todas as entradas customizadas do crontab, além do script mencionado acima, que registra o contador a cada cinco minutos. Os aumentos no contador não parecem estar correlacionados com este script executado em cron . O Anacrontab também não possui entradas personalizadas.

Resultados do registro em log

Comecei a registrar o valor do contador a cada cinco minutos por vários dias. Em um dia típico, aqui estão os resultados: Depois de um reinício do computador, eu entrei através do SSH. O contador estava em 1 para a duração da minha sessão, que durou algumas horas. Em seguida, desativei a rede e efetuei login na máquina física (usando o KDE DE). O contador estava em 1 por 50 minutos e, em seguida, pulou para 3. Eu tinha habilitado wifi por volta dessa hora. Uma hora depois, o número saltou para 420. Cinco minutos depois, foi em 537, onde ficou até eu desligar a máquina, pelo menos meia hora depois.

w mostrou três linhas: uma em tty7, uma em pts / 1 ( kdeinit4: kded4 [kdeinit] ) e uma em pts / 3 (o terminal em que eu estava usando w in). Assim, acho que não foram 537 usuários logados no meu computador. O que poderia estar acontecendo aqui?

Mais tarde, comecei a registrar o contador em /dev/shm/ecryptfs-$USER-Private a cada minuto e, em seguida, examinei o log do sistema em / var / sys / syslog durante alguns minutos, durante os quais o contador aumentou. A única coisa que pude ver que foi consistente em minutos durante os quais o contador aumentou foi um fluxo constante de linhas "[UFW BLOCK]" (para ficar claro, eu uso ufw como um firewall de sistema e só tenho uma porta aberta , para SSH). Nada parece ser consistente de incidente para incidente, exceto para o meu trabalho cron que registra o contador (essa tarefa cron não está sempre associada a um aumento no contador e não estava presente quando o problema começou).

O que devo tentar em seguida para descobrir isso? Ficarei muito grato por qualquer conselho ou idéias.

    
por J L 15.03.2013 / 07:09

1 resposta

0

O contador em /dev/shm/ecryptfs-my_user_name-Private parece ser gerenciado pela configuração de desmontagem automática em ecryptfs. Alguns guias recomendaram a remoção de ~/.ecryptfs/auto-umount para obter multi-plexers de terminal como screen e tmux para reproduzir com ecryptfs (consulte link , link ). Quando você remove ~/.ecryptfs/auto-umount , o ecryptfs auto-unmounter para de acompanhar este contador, pelo menos ele não o decrementa mais.

Também notei que o ecryptfs não criptografa novamente meu diretório pessoal mesmo depois de restaurar ~/.ecryptfs/auto-umount . Para corrigir isso, adicionei o seguinte ao meu ~/.bash_logout para permitir que o contador seja diminuído corretamente ao usar screen :

# needed for preventing ecryptfs auto-umount if screen is running
# from https://serverfault.com/questions/536407/tmux-and-encryptfs-causing-unreachable-directories-upon-reconnect
screenout='screen -ls | head -1 | awk '{print $1}''
if [ "$screenout" == "No" ]; then
        # screen isn't running
        touch $HOME/.ecryptfs/auto-umount
else
# screen session still running
    if [ -e $HOME/.ecryptfs/auto-umount ]; then
            rm $HOME/.ecryptfs/auto-umount
    fi
    # handle counter manually since removing it 
    count='cat /dev/shm/ecryptfs-username-Private'
    # decrement counter
    let count--
    # write decremented value to counter file
    echo $count > /dev/shm/ecryptfs-username-Private
fi

Pode ser necessário redefinir manualmente o contador usando echo 1 > /dev/shm/ecryptfs-username-Private e, em seguida, efetuar logout. Eu testei e minha .bash_logout modification parece ser uma solução válida para o problema.

    
por 12.05.2014 / 19:32