Файли неправильно вважаються пошкодженими в томі encfs


8

Я використовую encfs @1.7.5і osxfuse @2.6.4встановлюю через MacPorts 2.2.1 на моєму MacBook Pro Retina Late 2013, на якому працює ОС X Mavericks 10.9.2. Відкриваючи певні файли (наприклад, xlsx, pdf) у своєму encfsтомі, я отримую помилку "X пошкоджено і неможливо відкрити". а також пропозиція перенести його у кошик. Однак, коли я копіюю цей файл в іншому місці (тобто не на encfsтомі), він, здається, працює добре. Чому це?

EDIT: Я заглянув в Інтернет і знайшов повідомлення про відключення GateKeeper. Це зробило трюк. По суті, ви переходите до "Налаштування безпеки -> Безпека та конфіденційність -> Дозволити завантажувати програми з будь-якого місця".

Я розумію, що рішення працює, але хотілося б знати, чому воно працює. Заздалегідь спасибі.

EDIT 2: Також, якщо хтось міг би позначити мою публікацію encfs, це буде дуже вдячно.

Відповіді:


6

Я знайшов відповідь тут (для BoxCryptor):

За особливих обставин Mac OS X додає розширений атрибут 'com.apple.quarantine' у файл, який, наприклад, був завантажений з Інтернету. Це також може статися з файлами в папці BoxCryptor. Якщо зашифрований файл має цей розширений набір атрибутів, ви отримуєте повідомлення про помилку "пошкоджено" при спробі відкрити файл простого тексту в томі BoxCryptor.

Спробуйте також цей, більш безпечний спосіб вирішення:

x) Відкритий термінал (Програми -> Утиліти)

y) Виконайте таку команду (замініть шлях):

$ xattr -r -d com.apple.quarantine / шлях / до / encfs / mount / point


2

@apmouse правильна: ви можете відновити файл за допомогою xattr. Але робити це потрібно неодноразово - кожен раз, коли ви зберігаєте файл, до нього буде доданий прапор карантину.

Як ви вказали, є менш безпечна, але зручніша альтернатива: відключити GateKeeper.

Як відключити воротаря

Я розумію, що рішення працює, але хотілося б знати, чому воно працює. Заздалегідь спасибі.

Перше, що слід зазначити, це те, що якщо зайти в Keynote і вибрати File → Open, ви можете відкрити "пошкоджений" файл без проблем. Це означає, що насправді Finder втручається, щоб запобігти відкриттю файлу.

Повідомлення про помилку "_____ пошкоджено і неможливо відкрити" - це насправді помилка підпису (див. Тут - приблизно 3/4-х убік), тобто GateKeeper не може перевірити дійсну підпис. Перевірка підписів повинна бути застосована до виконуваних файлів, і я досі не зрозумів, чому це помилка в цій ситуації.

Я спробував скласти файлову систему зразкового циклу osxfuse і помістити туди такий самий "пошкоджений" файл, і він відкриється просто чудово. Тому я думаю, що ця помилка характерна для файлів encfs - а не для osxfuse взагалі.

Для чого це варто, на проект osxfuse відкритий квиток на цю точну проблему. Якщо у вас є ця проблема, опублікуйте свої дані в цьому квитку.

Сподіваюся, це допомагає ...


Я думав, що Gatekeeper впливає лише на додатки, а не на документи. То як це впливає на файли .xlsx?
користувач151019

Я здогадуюсь, що прапор застосовується до всіх завантажених документів, як у відповіді @ apmouse, але не "примусовий" для неприкладних програм, а з глюкозною поведінкою на зашифрованих томах. Мені потрібно перевірити цю поведінку на sshfsінших файлових системах FUSE, щоб бути впевненим.
Ніколя Де Джей

2

Я не знаю, чому у яблука не існує простого способу сказати "цей об'єм безпечний", але проблему можна вирішити досить просто для файлів encfs. Будь ласка, знайдіть нижче сценарій, який я використовую для монтажу томів encfs; він автоматично вирішує проблему атрибутів, а також допомагає при запам’ятовуванні закрити томи. Його можна розширити, прочитавши encfs dir та точку монтуванняз командного рядка, але я віддаю перевагу не тому, що помилки друку можуть створювати ризики для безпеки. Він повинен бути досить легко адаптований до інших механізмів кріплення, таких як boxcryptor. Це працює для мене, але ви покладаєтесь на власну експертизу, вирішуючи, чи використовувати його для себе. Зокрема, я не є експертом з питань безпеки та не кваліфікований для того, щоб оцінювати, чи відкриває він якісь дірки в безпеці (особливо під час роботи, і особливо на спільних машинах).

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

Я думаю, у мене є більш стійкий спосіб вирішення цього питання, а не команда, яку потрібно виконувати кожен раз. Як я щойно згадував у звіті про помилку вище за течією :

Я подумав собі, що OS X використовує системних користувачів та системні демони для будь-яких завдань, можливо, ядро ​​очікує, що зможе виконати якусь роботу як інший користувач, або як root, для цих файлів, і позначивши їх як пошкоджені, коли це не працює.

Тож я позначив свій sshfsбінарний файл як setuidі додав -o allow_otherваріант монтажу до свого sshfsкомандного рядка, і ... я, здається, зможу надійно відкривати та редагувати документи на встановленому томі. Я буду продовжувати експерименти та слідкувати, якщо він перестане працювати.

Я, звичайно, стурбований встановленим кореневим бінарним файлом, який лежить навколо, але це здається кращим, ніж варіант запуску демона, який вимагає привілеїв root на стороні файлового сервера , щоб отримати NFS або SMB. :)

Враховуючи, що allow_otherце варіант FUSE кріплення, який не є специфічним для sshfs, я вважаю, що це рішення також буде спрацьовувати encfs. Було б чудово знати, чи хтось спробував це, і це спрацювало!


1

Дякую @Glyph, наскільки я можу сказати, він, здається, працює після виконання ваших кроків. Я дотримувався цих кроків:

  1. Спершу мені довелося додати групу, до якої я належу до адмінгрупи osxfuse, інакше дозволити інший не вдасться, якщо операція не підтримується.

    sysctl -w osxfuse.tunables.admin_group=12
    
  2. Потім використовуйте -o enable_other для encfs

Я лише трохи спробував це, але, здавалося б, справа про відмову, яку я повторював, зараз працює.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.