Pliki błędnie uznane za uszkodzone w woluminie encfs


8

Używam encfs @1.7.5i osxfuse @2.6.4instaluję za pośrednictwem MacPorts 2.2.1 na moim MacBooku Pro Retina z końca 2013 roku z systemem OS X Mavericks 10.9.2. Podczas otwierania niektórych plików (np. Xlsx, pdf) w moim encfswoluminie pojawia się błąd „X jest uszkodzony i nie można go otworzyć”. a także sugestię, aby przenieść go do kosza. Jednak gdy kopiuję ten plik w innym miejscu (tj. Nie na encfswoluminie), wydaje się, że działa dobrze. Dlaczego to?

EDYCJA: Szukałem online i znalazłem post dotyczący wyłączenia GateKeeper. To załatwiło sprawę. Zasadniczo należy przejść do „Preferencji bezpieczeństwa -> Bezpieczeństwo i prywatność -> Zezwól aplikacjom pobieranym z: Gdziekolwiek”.

Rozumiem, że rozwiązanie działa, ale chciałbym wiedzieć, dlaczego działa. Z góry dziękuję.

EDYCJA 2: Gdyby ktoś mógł otagować mój post encfs, byłoby to bardzo mile widziane.

Odpowiedzi:


6

Znalazłem odpowiedź tutaj (dla BoxCryptor):

W szczególnych okolicznościach Mac OS X dodaje rozszerzony atrybut „com.apple.quarantine” do pliku, który został np. Pobrany z Internetu. Może się to zdarzyć również w przypadku plików w folderze BoxCryptor. Jeśli zaszyfrowany plik ma ten rozszerzony zestaw atrybutów, pojawia się komunikat o błędzie „jest uszkodzony” podczas próby otwarcia pliku tekstowego w woluminie BoxCryptor.

Wypróbuj również to, bardziej bezpieczne obejście:

x) Otwórz terminal (Aplikacje -> Narzędzia)

y) Uruchom następującą komendę (zamień ścieżkę):

$ xattr -r -d com.apple.quarantine / path / to / encfs / mount / point


2

@apmouse jest poprawny: możesz naprawić plik za pomocą xattr. Ale musisz to robić wielokrotnie - za każdym razem, gdy zapiszesz plik, zostanie do niego dodana flaga kwarantanny.

Jak zauważyłeś, istnieje mniej bezpieczna, ale wygodniejsza alternatywa: wyłącz GateKeeper.

jak wyłączyć strażnika

Rozumiem, że rozwiązanie działa, ale chciałbym wiedzieć, dlaczego działa. Z góry dziękuję.

Pierwszą rzeczą do zapamiętania jest to, że jeśli przejdziesz do Keynote i wybierzesz Plik → Otwórz, możesz otworzyć „uszkodzony” plik bez żadnych problemów. Oznacza to, że w rzeczywistości interweniuje Finder , aby zapobiec otwarciu pliku.

Komunikat o błędzie „_____ jest uszkodzony i nie można go otworzyć” jest w rzeczywistości błędem podpisu (patrz tutaj - około 3/4 drogi w dół), co oznacza, że ​​GateKeeper nie może zweryfikować poprawnego podpisu. Weryfikacja podpisów ma być stosowana do plików wykonywalnych, a ja wciąż nie wiem, dlaczego w tej sytuacji się psuje.

Próbowałem skompilować przykładowy system plików sprzężenia zwrotnego osxfuse i umieścić tam ten sam „uszkodzony” plik, a on otwiera się dobrze. Myślę więc, że ten błąd jest specyficzny dla encfs - a nie ogólnie dla osxfuse.

Za to, co jest warte, w projekcie osxfuse jest otwarty bilet na ten właśnie problem. Jeśli masz ten problem, opublikuj swoje dane na tym bilecie.

Mam nadzieję że to pomoże...


Myślałem, że Gatekeeper wpływa tylko na aplikacje, a nie na dokumenty. Jak to wpływa na pliki .xlsx?
user151019,

Domyślam się, że flaga jest stosowana do wszystkich pobranych dokumentów, jak w odpowiedzi @ apmouse, ale nie jest „wymuszana” w aplikacjach innych niż aplikacje, ale zachowuje się glitchy na zaszyfrowanych woluminach. Muszę przetestować to zachowanie na sshfsinnych systemach plików FUSE, aby się upewnić.
Nicolas De Jay

2

Nie wiem, dlaczego jabłko nie wydaje się mieć prostego sposobu na powiedzenie „ten wolumin jest bezpieczny”, ale problem jest dość łatwy do rozwiązania dla enkfonów. Poniżej znajduje się skrypt, którego używam do montowania woluminów encfs; automatycznie rozwiązuje problem atrybutów, a także pomaga pamiętać o zamykaniu woluminów. Można go rozszerzyć, czytając katalog enfs i katalog montowaniaz wiersza poleceń, ale wolę tego nie robić, ponieważ literówki mogą powodować zagrożenia bezpieczeństwa. Należy go stosunkowo łatwo dostosować do innych mechanizmów montowania, takich jak boxcryptor. Działa to dla mnie, ale przy podejmowaniu decyzji, czy użyć go dla siebie, musisz polegać na własnej wiedzy. Mówiąc dokładniej, nie jestem ekspertem od bezpieczeństwa i nie mam uprawnień, aby oceniać, czy otwiera on luki w zabezpieczeniach (szczególnie podczas działania, a zwłaszcza na współdzielonych komputerach).

#!/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

2

Wydaje mi się, że mam bardziej trwałe obejście tego problemu niż polecenie, które należy wykonywać za każdym razem. Jak właśnie wspomniałem w poprzednim raporcie o błędzie :

Pomyślałem sobie, że OS X używa użytkowników systemu i demonów systemowych do wszelkiego rodzaju zadań, być może jądro spodziewa się być w stanie wykonać jakąś pracę jako inny użytkownik lub jako root dla tych plików i oznaczyć je jako uszkodzone, gdy nie działa

Tak więc oznaczyłem mój sshfsplik binarny jako setuidi dodałem -o allow_otheropcję montowania do sshfswiersza poleceń i ... wydaje się, że jestem w stanie niezawodnie otwierać i edytować dokumenty na zamontowanym woluminie. Będę nadal eksperymentować i sprawdzać, jeśli przestanie działać.

Oczywiście jestem zaniepokojony leżącym wokół plikiem setuid root, ale wydaje się to lepsze niż opcja uruchamiania demona, który wymaga uprawnień roota po stronie serwera plików , aby uzyskać NFS lub SMB. :)

Biorąc pod uwagę, że allow_otherjest to opcja montowania FUSE i nie jest specyficzna dla sshfs, uważam, że to obejście również zadziałałoby encfs. Byłoby wspaniale wiedzieć, gdyby ktoś spróbował i zadziałało!


1

Dzięki @Glyph, z tego, co mogę powiedzieć, wydaje się działać po wykonaniu twoich kroków. Wykonałem następujące kroki:

  1. Najpierw musiałem dodać grupę, którą należę do grupy administracyjnej osxfuse, w przeciwnym razie parametr allow_other nie powiedzie się, a operacja nie będzie obsługiwana.

    sysctl -w osxfuse.tunables.admin_group=12
    
  2. Następnie użyłem opcji -o allow_other do szyfrowania

Próbowałem tylko przez chwilę, ale zdaje się, że teraz odtwarzalny przypadek awarii działa.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.