在encfs卷中错误地认为文件已损坏


8

我正在运行OS X Mavericks 10.9.2的MacBook Pro Retina 2013晚期上使用MacPorts 2.2.1 encfs @1.7.5osxfuse @2.6.4通过其安装。在我的encfs卷中打开某些文件(例如xlsx,pdf)时,出现错误“ X已损坏,无法打开”。以及将其移至垃圾桶的建议。但是,当我将该文件复制到其他位置(即不在encfs卷上)时,它似乎工作正常。为什么是这样?

编辑:我在网上看了看,发现了一个涉及禁用GateKeeper 的帖子。它成功了。本质上,您进入“安全首选项->安全和隐私->允许从以下位置下载应用程序”。

我知道该解决方案有效,但是我想知道它为什么有效。提前致谢。

编辑2:另外,如果有人可以用标记我的帖子encfs,将不胜感激。

Answers:


6

我在这里找到了答案(对于BoxCryptor):

在特殊情况下,Mac OS X将扩展属性“ com.apple.quarantine”添加到例如从Internet下载的文件中。BoxCryptor文件夹中的文件也可能发生这种情况。如果加密的文件设置了此扩展属性,则在打开BoxCryptor卷中的纯文本文件时会收到“已损坏”错误消息。

还可以尝试以下更安全的解决方法:

x)打开终端(应用程序->实用程序)

y)运行以下命令(替换路径):

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


2

@apmouse是正确的:您可以使用xattr修复文件。但是您必须重复执行此操作–每次保存文件时,都会将隔离标志添加回该文件中。

正如您所指出的,有一个不太安全但更方便的选择:禁用GateKeeper。

如何禁用网守

我知道该解决方案有效,但是我想知道它为什么有效。提前致谢。

首先要注意的是,如果进入Keynote并选择“文件”→“打开”,则可以打开“已损坏”的文件而没有任何问题。这意味着实际上是Finder介入以防止打开文件。

错误消息“ _____已损坏且无法打开”实际上是一个签名错误(请参阅此处 -大约3/4处),这意味着GateKeeper无法验证有效的签名。签名验证应该应用于可执行文件,但我仍然不知道为什么在这种情况下会进行签名验证。

我尝试编译osxfuse的样本回送文件系统,然后将相同的“损坏”文件放在该文件系统上,这样就可以正常打开了。因此,我认为此错误是特定于encfs的,而不是通常的osxfuse。

对于它的价值,在osxfuse项目上有一张票可以解决这个确切的问题。如果您遇到此问题,请在该票证上张贴您的详细信息。

希望这可以帮助...


我以为Gatekeeper仅会影响应用程序,而不会影响文档。那么,它如何影响.xlsx文件?
user151019 2014年

我的猜测是,该标志将应用于所有下载的文档,就像@apmouse的答案一样,但不是在非应用程序上“强制执行”,而是在加密卷上出现故障。我需要在sshfs其他FUSE文件系统上测试此行为,以确保。
Nicolas De Jay

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_othermount选项sshfs,然后...我似乎能够可靠地在已装载的卷上打开和编辑文档。我将继续尝试并继续进行后续操作。

我当然关心一个setuid根二进制文件,但是它似乎比运行一个守护程序更好,后者需要在文件服务器端具有root特权才能获得NFS或SMB。:)

鉴于这allow_other是一个FUSE挂载选项,而不是特定于的sshfs,所以我认为此替代方法也适用encfs。知道是否有人尝试过并且成功了将非常高兴!


1

感谢@Glyph,据我所知,在按照您的步骤操作后,它似乎正在工作。我按照以下步骤操作:

  1. 首先,我必须添加一个属于osxfuse admin组的组,否则allow_other会因不支持的操作而失败。

    sysctl -w osxfuse.tunables.admin_group=12
    
  2. 然后使用-o allow_other来encfs

我只尝试了一下,但是我现在出现的可再现失败案例似乎正在起作用。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.