Access of removable volumes from file provider on macOS Sequoia

Question

sadasdasrewrew OP

Created Sep ’24

Replies 3

Boosts 0

Participants 2

Hello,

I developed a file provider extension that can access files from multiple locations. With the new macOS Sequoia I cannot access files from volumes, here is the error from Console:

Refusing TCCAccessRequest for service kTCCServiceSystemPolicyRemovableVolumes from extension Sub:{com.app.ext}Resp:{TCCDProcess: identifier=com.app.ext-Driver, pid=26706, auid=501, euid=501, binary_path.... Driver}, extension point disallows prompting

I added "Privacy - Removable Volumes Usage Description" values for both the main app and extension Info.plist, I click Allow on the alert, but still I receive this error message.

Any solution? Thank you.

Answered by DTS Engineer in 804417022

start() will trigger the Removable Volume access request, this time inside the FileProvider. This is where it fails, see above the error message. I don't know why it triggers again the request, the main app is already confirmed.

I suspect the issue here is that part of ICDeviceBrowser's implementation lives out of process and that check isn't accounting for how permissions might be inherited.

IV. In the FileProvider class I connect to the scanner, but to connect to a scanner I must start again a device browser monitor in order to have a reference to the actual scanner device:

Is there any reason why your main app couldn't transfer a reference over to your file provider. There's a section of "Accessing files from the macOS App Sandbox" that covers how to do this.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’24

I developed a file provider extension that can access files from multiple locations. With the new macOS Sequoia I cannot access files from volumes, here is the error from Console:

How is your file provider getting access to those locations? I would have expected a security scoped reference to avoid this dialog, but I might be wrong about that. Also, what happens if you approve your main app for volume access? App extensions are generally inherit authorization from their parent app.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

sadasdasrewrew OP

Sep ’24

Hello, The "Removable Volume access request" is actually triggered by a start() call to ICDeviceBrowser (this class can scan for cameras and scanners connected to the computer)

The flow is like this:

I. In the main app discovers the connected scanners or cameras like this:

let browser: ICDeviceBrowser
browser.start() // This will trigger the Removable Volume access request

II. I accept the request and devices are discovered and connected.

III. After a device is discovered I create a new FileProvider extension for the new connected device.

IV. In the FileProvider class I connect to the scanner, but to connect to a scanner I must start again a device browser monitor in order to have a reference to the actual scanner device:

let browser: ICDeviceBrowser
browser.start()

start() will trigger the Removable Volume access request, this time inside the FileProvider. This is where it fails, see above the error message. I don't know why it triggers again the request, the main app is already confirmed.

This workflow worked fine until now (before macOS Sequoia).

Thank you.

0

Answer 3

DTS Engineer OP

Apple

Sep ’24

Accepted Answer

start() will trigger the Removable Volume access request, this time inside the FileProvider. This is where it fails, see above the error message. I don't know why it triggers again the request, the main app is already confirmed.

I suspect the issue here is that part of ICDeviceBrowser's implementation lives out of process and that check isn't accounting for how permissions might be inherited.

IV. In the FileProvider class I connect to the scanner, but to connect to a scanner I must start again a device browser monitor in order to have a reference to the actual scanner device:

Is there any reason why your main app couldn't transfer a reference over to your file provider. There's a section of "Accessing files from the macOS App Sandbox" that covers how to do this.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0