É seguro alterar os arquivos criptografados subjacentes para um volume ecryptfs montado ao vivo?

Question

Eu quero fazer a sincronização ao vivo de um diretório criptografado com um servidor, de modo que o servidor veja somente dados criptografados.

Suponha que eu coloque os dados ecryptfs subjacentes em:

/home/user/.Private

E eu montei esse diretório em:

/home/user/unlocked

Posso atualizar os arquivos em .Private (por exemplo, usando rsync) e esperar unlocked para refletir as alterações? Ou isso vai apenas estragar as coisas? Existem alternativas melhores para a sincronização ao vivo de dados criptografados?

ATUALIZE para esclarecer:

Eu só quero transmitir dados criptografados para o servidor - o servidor não é confiável. Então eu quero ver:

 client <-- encrypted data --> server

Pode haver mais de um cliente atualizando arquivos (descriptografados); daí o desejo de sincronização ao vivo:

 client1
        \
         \--- encrypted data --\
                                \
                                 server
                                /
         /--- encrypted data --/
        /
 client2

Portanto, o cliente tem um diretório contendo arquivos criptografados - segmentado da maneira que o ecryptfs faz:

/home/client1/.Private/
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Fabcde.../
                 |                                    |--- ECRYPTFS_FNEK_...
                 |
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Flaksd.../
                                                      |--- ...

Isto é montado com ecryptfs:

/home/client1/unlocked/
                 |--- secret_file_1
                 |--- secret_file_2

Agora, o client1 está realizando alterações nos arquivos em unlocked . Quando o cliente faz alterações, os arquivos criptografados subjacentes em .Private também são alterados. Assim, um local inotify ou algum tal notifica as alterações e rsyncs os arquivos base criptografados em .Private para o servidor. O servidor, ciente de que o client2 também está escutando, notifica o client2 de que ele deve receber mudanças.

Então, minha preocupação é: Se o client2 extrair os arquivos fragmentados do encryptfs subjacentes em .Private enquanto estiver montado em unlocked , suspeito que isso causará problemas, não? Isso exigiria que o client2 desmontasse unlocked antes da sincronização, o que anula toda a ideia de "sincronização ao vivo".

Em caso afirmativo, quais são boas técnicas alternativas para sincronização eficiente de diffs de uma árvore criptografada?

    

Answer 1

De acordo com Tyler Hicks (um dos mantenedores do eCryptfs), atualmente não é seguro modificar o sistema de arquivos subjacente (sistema de arquivos inferior na terminologia do eCryptfs):

It would be good if eCryptfs could detect lower file data changes and update the cache to see the file updated.

     

Mesmo se pudéssemos detectá-los, como os mediaríamos contra a sujeira?   páginas eCryptfs? Como sabemos quais são os dados mais atualizados?

     

Infelizmente, as modificações diretas no sistema de arquivos inferior são simplesmente   não suportado. Se uma modificação não passar pela montagem eCryptfs   ponto, não podemos esperar que você saiba sobre isso devido ao eCryptfs   arquitetura.

Fonte: link

    

Answer 2

Para atualizar arquivos no sistema de arquivos ecryptfs você precisa atualizá-los no ponto de montagem - no sistema de arquivos criptografado você precisaria atualizar a coisa toda de uma vez, já que não tem nenhum conceito de arquivos ou diretórios - é apenas um grande pedaço de dados.

Sim, você pode usar o rsync para fazer backup dos dados em algum lugar, mas para ler ou gravar um arquivo específico, é necessário montá-lo.

Você pode montá-lo de vários lugares diferentes (provavelmente é melhor não tentar isto simultaneamente :-) então porque não usar um script de shell que monta, os arquivos relevantes do rsync e desmonta sempre que arquivos relevantes são atualizados?

informações úteis aqui