erros de cabeçalhos eCryptfs

3

Estou recebendo o seguinte erro em um servidor no qual uma partição é criptografada por meio do ecryptfs.

[3440851.003561] Valid eCryptfs headers not found in file header region or xattr region, inode 22545087
[3440830.026081] Valid eCryptfs headers not found in file header region or xattr region, inode 22553905

Depois de desmontar a partição criptografada e a partição ext4 abaixo, executei um fsck que me deu o seguinte resultado:

fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sda3: clean, 65092/72302592 files, 54219978/289200384 blocks

Estou um pouco sem noção para entender o que acontece. Estamos usando a mesma configuração em várias instâncias e observamos isso em apenas uma delas.

A solução pode ser mudar os discos subjacentes! Mas eu gostaria de entender o que aconteceu, a fim de eventualmente detectar e prevenir esse tipo de incidente.

    
por ohe 23.12.2015 / 12:10

2 respostas

2

Eu vi isso acontecer quando o sistema não foi desligado corretamente. Particularmente, vi isso acontecer quando os dados criptografados foram armazenados em um dispositivo USB, onde a conexão entre o host e o dispositivo USB era um pouco incerta. Mas acredito que outros desligamentos não limpos enquanto os arquivos estão sendo gravados também podem causar isso.

Pesquisando por inode como sugerido na resposta por Giovanni pode realmente ser usado para encontrar o arquivo problemático. Como o ecryptfs preserva os números de inode do sistema de arquivos subjacente, esse comando pode ser usado para localizar o caminho criptografado e não criptografado para o arquivo.

A pesquisa pelo arquivo no sistema de arquivos subjacente dessa forma é significativamente mais rápida do que a pesquisa no sistema de arquivos ecryptfs. Minhas medições em um sistema mostraram uma desaceleração por um fator de 8 entre os dois com caches frios e um fator de 350 diferença com caches quentes.

Devido a essa sobrecarga, sugiro que você encontre primeiro o arquivo criptografado no sistema de arquivos subjacente. Por exemplo, na configuração padrão em um sistema Ubuntu, este comando pode ser usado:

find /home/.ecryptfs -inum 22545087

Isso deve encontrar o caminho para o arquivo criptografado, que inclui o nome do diretório inicial em que foi encontrado. Então, ao pesquisar pelo nome do arquivo não criptografado, você pode limitar imediatamente a pesquisa a apenas um diretório inicial:

find /home/username -inum 22545087

Se o usuário tiver tantos arquivos que isso seja muito lento, você poderá aproveitar os números de inode para procurar um nível de diretório por vez. Por exemplo, se o nome do arquivo criptografado era

/home/.ecryptfs/username/.Private/ECRYPTFS_FNEK_ENCRYPTED.AAAAAA/ECRYPTFS_FNEK_ENCRYPTED.BBBBBB/ECRYPTFS_FNEK_ENCRYPTED.CCCCCC

Você pode primeiro executar

ls -i /home/.ecryptfs/username/.Private/ECRYPTFS_FNEK_ENCRYPTED.AAAAAA

Isso lhe dará o número de inode do diretório mais externo. Você pode então procurar a versão não criptografada desse nome de diretório:

ls -i /home/username | grep $INODE_NUMBER_FROM_LS

Você pode repetir isso para cada nível na hierarquia de diretórios para obter o caminho não criptografado sem ter que usar tanto tempo de CPU quanto necessário para descriptografar cada nome de arquivo nesse diretório inicial.

    
por 01.01.2016 / 23:47
1

Descubra qual arquivo está causando isso por meio de:

find / -inum <inode number>

Você provavelmente encontrará um arquivo truncado, e essa é a razão pela qual o ecryptfs está aumentando esse aviso.

Tente ler o arquivo com cat e rm para corrigir o aviso.

    
por 29.12.2015 / 18:14