Files wrongly considered as damaged in encfs volume

Question

I am using encfs @1.7.5 and osxfuse @2.6.4 installed via MacPorts 2.2.1 on my MacBook Pro Retina Late 2013 which is running OS X Mavericks 10.9.2. When opening certain files (e.g. xlsx, pdf) in my encfs volume, I get an error "X is damaged and can't be opened." as well as a suggestion to move it to trash. However, when I copy that file elsewhere (i.e. not on the encfs volume), it appears to work just fine. Why is this?

EDIT: I looked online and found a post involving disabling GateKeeper. It did the trick. In essence, you go into "Security Preferences -> Security & Privacy -> Allow applications downloaded from: Anywhere".

I understand that the solution works, but I would like to know why it works. Thanks in advance.

EDIT 2: Also, if someone could tag my post with encfs, it'd be very appreciated.

Answer 1

I've found the answer here (for BoxCryptor):

Under special circumstances, Mac OS X adds the extended attribute 'com.apple.quarantine' to a file which was e.g. downloaded from the internet. This can also happen to files within the BoxCryptor Folder. If an encrypted file has this extended attribute set, you receive the "is damaged" error message when trying to open the plaintext file in the BoxCryptor Volume.

Also try this, more secure workaround:

x) Open Terminal (Applications -> Utilities)

y) Run the following command (substitute the path):

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

Answer 2

@apmouse is correct: you can repair the file with xattr. But you have to do that repeatedly – every time you save a file it will have the quarantine flag added back to it.

As you pointed out, there's a less safe but more convenient alternative: disable GateKeeper.

I understand that the solution works, but I would like to know why it works. Thanks in advance.

The first thing to note is that if you go into Keynote and choose File → Open, you can open the "damaged" file without any issues. This implies that it is actually Finder that is intervening to prevent opening the file.

The error message "_____ is damaged and can't be opened" is actually a signature error (see here – about 3/4ths of the way down), meaning that GateKeeper can't verify a valid signature. Signature verification is supposed to be applied to executables, and I still haven't figured out why it's bugging out in this situation.

I tried compiling the osxfuse's sample loopback file system and putting the same "damaged" file on there and it opens just fine. So I think this bug is specific to encfs – not to osxfuse in general.

For what it's worth, there is a ticket open on the osxfuse project for this exact problem. If you're having this problem, post your details on that ticket.

Hope this helps...

Answer 3

I don't know why apple don't appear to have a simple way to say "this volume is safe", but the problem is fairly easy to solve for encfs. Please find below a script I use for mounting encfs volumes; it automatically solves the attribute problem, and also helps with remembering to close volumes. It could be extended by reading encfs dir and mount point from the command line, but I prefer not to because typos might create security risks. It should be relatively easily adapted to other mount mechanisms, such as boxcryptor. It works for me, but you rely on your own expertise in deciding whether to use it for yourself. Very specifically, I am not a security expert, and am not qualified to judge whether it opens any security holes (especially while it is running, and especially on shared machines).

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

Answer 4

I think I have a more persistent workaround for this rather than a command you need to run each time. As I just mentioned on the bug report upstream:

I thought to myself, OS X uses system users and system daemons for all kinds of jobs, perhaps the kernel is expecting to be able to do some work as another user, or as root, to these files, and marking them as damaged when that doesn't work.

So I marked my sshfs binary as setuid, and I added the -o allow_other mount option to my sshfs command line, and ... I appear to be able to open and edit documents reliably on the mounted volume. I will continue to experiment and follow up if it stops working.

I am of course concerned about a setuid root binary lying around, but it seems better than the option of running a daemon which requires root privileges on the file server side of things to get NFS or SMB. :)

Given that allow_other is a FUSE mount option and not specific to sshfs, I believe that this workaround would work for encfs as well. It would be great to know if someone tried it and it worked!

Answer 5

Thanks @Glyph , from what I can tell it appears to be working after following your steps. I followed these steps:

1. First I had to add a group which I belong to the osxfuse admin group, otherwise the allow_other would fail with operation not supported.

   sysctl -w osxfuse.tunables.admin_group=12
   

2. Then used the -o allow_other to encfs

I've only tried it for a bit, but the reproduceable failure case I had appears to now be working.