Arquivos considerados incorretamente danificados no volume encfs

Estou usando encfs @1.7.5e osxfuse @2.6.4instalado via MacPorts 2.2.1 no meu MacBook Pro Retina, final de 2013, que está executando o OS X Mavericks 10.9.2. Ao abrir certos arquivos (por exemplo, xlsx, pdf) no meu encfsvolume, recebo o erro "X está danificado e não pode ser aberto". bem como uma sugestão para movê-lo para o lixo. No entanto, quando copio esse arquivo em outro lugar (ou seja, não no encfsvolume), ele parece funcionar muito bem. Por que é isso?

EDIT: Procurei on-line e encontrei uma postagem envolvendo a desativação do GateKeeper. Ele fez o truque. Em essência, você acessa "Preferências de segurança -> Segurança e privacidade -> Permitir aplicativos baixados de: em qualquer lugar".

Entendo que a solução funciona, mas gostaria de saber por que ela funciona. Desde já, obrigado.

EDIÇÃO 2: Além disso, se alguém pudesse marcar minha postagem encfs, seria muito apreciada.

Encontrei a resposta aqui (para BoxCryptor):

Sob circunstâncias especiais, o Mac OS X adiciona o atributo estendido 'com.apple.quarantine' a um arquivo que foi, por exemplo, baixado da Internet. Isso também pode acontecer com arquivos na pasta BoxCryptor. Se um arquivo criptografado tiver esse atributo estendido definido, você receberá a mensagem de erro "está danificado" ao tentar abrir o arquivo de texto sem formatação no volume BoxCryptor.

Tente também isso, solução alternativa mais segura:

x) Terminal aberto (Aplicativos -> Utilitários)

y) Execute o seguinte comando (substitua o caminho):

$ xattr -r -d com.apple.quarantine / caminho / para / encfs / mount / point

@apmouse está correto: você pode reparar o arquivo com o xattr. Mas você precisa fazer isso repetidamente - sempre que salvar um arquivo, ele será adicionado novamente ao sinalizador de quarentena.

Como você apontou, há uma alternativa menos segura, mas mais conveniente: desative o GateKeeper.

Entendo que a solução funciona, mas gostaria de saber por que ela funciona. Desde já, obrigado.

A primeira coisa a observar é que, se você entrar no Keynote e escolher Arquivo → Abrir, poderá abrir o arquivo "danificado" sem problemas. Isso implica que, na verdade, é o Finder que está intervindo para impedir a abertura do arquivo.

A mensagem de erro "_____ está danificada e não pode ser aberta" é na verdade um erro de assinatura (veja aqui - cerca de 3/4 da metade do tempo), o que significa que o GateKeeper não pode verificar uma assinatura válida. A verificação de assinatura deve ser aplicada aos executáveis, e ainda não descobri por que está ocorrendo algum problema nessa situação.

Tentei compilar o sistema de arquivos de loopback de amostra do osxfuse e colocar o mesmo arquivo "danificado" lá e ele abre muito bem. Então eu acho que esse bug é específico para encfs - não para osxfuse em geral.

Pelo que vale, existe um ticket aberto no projeto osxfuse para esse problema exato. Se você está tendo esse problema, publique seus detalhes nesse ticket.

Espero que isto ajude...

Não sei por que a apple parece não ter uma maneira simples de dizer "este volume é seguro", mas o problema é bastante fácil de resolver para encfs. Por favor, encontre abaixo um script que eu uso para montar volumes encfs; ele resolve automaticamente o problema do atributo e também ajuda a lembrar de fechar volumes. Pode ser estendido lendo encfs dir e ponto de montagemna linha de comando, mas prefiro não, porque erros de digitação podem criar riscos à segurança. Ele deve ser relativamente facilmente adaptado a outros mecanismos de montagem, como o boxcryptor. Funciona para mim, mas você depende de sua própria experiência para decidir se deve usá-lo para si mesmo. Muito especificamente, não sou especialista em segurança e não estou qualificado para julgar se ele abre brechas na segurança (especialmente enquanto está em execução e principalmente em máquinas compartilhadas).

#!/bin/bash
# script to mount encrypted volume

ENCFSDIR=<encfs dir>
MOUNTPOINT=<mount point>
SAFELOC=<somewhere outside mounted volume>

encfs $ENCFSDIR $MOUNTPOINT

cd $MOUNTPOINT
xattr -r -d com.apple.quarantine .
MY_PROMPT='SECRET: '
echo 'noscecrets to finish'
while :
do
  echo -n "$MY_PROMPT"
  read line
  if [ 'nosecrets' == "$line" ] ; then
    break
  fi
  eval "$line"
done

\# and clean up
cd $SAFELOC
umount $MOUNTPOINT

exit 0

Eu acho que tenho uma solução mais persistente para isso, em vez de um comando que você precisa executar sempre. Como acabei de mencionar no relatório de erros do autor :

Eu pensei comigo mesmo: o OS X usa usuários do sistema e daemons do sistema para todos os tipos de tarefas, talvez o kernel esteja esperando poder fazer algum trabalho como outro usuário, ou como root, nesses arquivos, marcando-os como danificados quando isso ocorrer. não funciona

Então marquei meu sshfsbinário como setuide adicionei a -o allow_otheropção de montagem à minha sshfslinha de comando, e ... Parece que consigo abrir e editar documentos de forma confiável no volume montado. Vou continuar a experimentar e acompanhar se ele parar de funcionar.

É claro que estou preocupado com um binário raiz setuid, mas parece melhor que a opção de executar um daemon que requer privilégios de root no servidor de arquivos para obter NFS ou SMB. :)

Como essa allow_otheré uma opção de montagem do FUSE e não é específica sshfs, acredito que essa solução alternativa também funcionaria encfs. Seria ótimo saber se alguém tentou e deu certo!

Obrigado @Glyph, pelo que posso dizer, parece estar funcionando depois de seguir seus passos. Eu segui estes passos:

1. Primeiro, tive que adicionar um grupo ao qual pertenço ao grupo de administração osxfuse, caso contrário, o allow_other falharia com a operação não suportada.

   sysctl -w osxfuse.tunables.admin_group=12
   

2. Em seguida, usei o -o allow_other para encfs

Eu tentei apenas um pouco, mas o caso de falha reproduzível que eu tive parece estar funcionando agora.