Full disk access using macOS privacy protection support

[var314]

Hi,

macOS Mojave introduced additional protection aimed towards privacy. It means that application does not have access to things like camera, contacts, photos library, etc. by default. In case of photos library, the files and folder permissions seems right, there is no ACLs and still the Syncthing cannot scan the folder with an error:

2019-02-21 22:28:03 Scanner (folder xsxxx-xxxxx, file "."): scan: open /Users/user/Pictures/Biblioteka Zdjęcia.photoslibrary/Masters: operation not permitted

Interestingly and confusingly, the .stfolder is created. The Console.app tells a little more if someone know what to look at:

Sandbox: syncthing(757) System Policy: deny(1) file-read-data /Users/user/Pictures/Biblioteka Zdjęcia.photoslibrary/Masters

There are two workarounds (at least two known to me):

1. Run Syncthing executable from terminal.

   $ /Applications/Syncthing.app/Contents/MacOS/Syncthing

   Note, that the below form will not work, it will have the same issue as Syncthing started by double click or auto started:

   $ open /Applications/Syncthing.app

2. Go to Sytem settings -> Security & privacy -> Privacy, choose Full access to disk category and add Syncthing (the names may be different, I have polish version and translated back to english). This will work with Syncthing started in any way.

   Note, that adding Syncthing to just Photos category is not possible. From what I have read the application must declare in a manifest that it requires the access and then explicitly ask user to grant it.

So I think that ideally Syncthing would ask user for permission to access photos library in such case. Less ideally, the error would mention that this may be the issue with macOS privacy protection (I do not know if this is official name). Otherwise it is really hard to find out what is going on. Especially for someone that do not know about that macOS feature.

The Syncthing-macos version is 1.0.0-2, Syncthing version is 1.0.1, macOS is Mojave version 10.14.3

[xor-gate]

Hi @var314, thanks for reporting this. This is a real problem, I think most people just have an Syncthing folder in their home directory which is why it doesn't get any problems. iTerm2 has documented it, not sure how it is implemented yet as I'm trying to find it in the source and apple developer docs which is a big pile. As reference for myself https://gitlab.com/gnachman/iterm2/wikis/fulldiskaccess.

[xor-gate]

As a reference, I asked the author of iTerm 2

Dear George,

I’m one of the main Syncthing for macOS developers and i’m not well known with all the macOS/Apple APIs but recently while upgrading to 10.14 the new security & privacy has gone to active. I tried navigating the big amount of iTerm2 code to figure out how you test and message the user for full disk access. It did found the wiki page https://gitlab.com/gnachman/iterm2/wikis/fulldiskaccess but this is only from user perspective. I would ask you if you could point me in the right direction how we also could implement this for #95.

Your help is highly appreciated, thanks in advance!

P.s I’m grate-full every day to use your awesome piece iTerm2 of software, thanks for you time and effort on this!

Kind regards,
Jerry Jacobs

• github.com/xor-gate

Answer

Hi Jerry,

The first approach I took was to see if I could open the ~/Library/Safari folder. It fails if you don't have full disk access. Unfortunately, it only exists after the user has run Safari, so that turns out not to be a great test. I didn't end up fixing it because it turned out that setting the NSSystemAdministrationUsageDescription Info.plist property causes an alert to be shown when a child process needs access to certain directories that require full disk access. You probably couldn't find my test because I deleted it after adding the plist key (see commit 0be751ed0a34910271ad25790f015881585e00d9). It's unlikely that the plist key would help you, unfortunately. I'd recommend doing something like I did with Safari, but try to find another folder that is guaranteed to always exist. Apple hasn't documented it so it just takes some experimentation. Maybe try opening every folder in the user's home directory for a brand new account.

[gabrielstuff]

This thread is really interesting: https://forums.developer.apple.com/thread/107546 What did you end up doing for this related issue with new Mojave policy ?

Thanks