How can I trigger the Full Disk Access prompt to write to a raw block device?

Question

coolaj86 OP

Created 4w

Replies 3

Boosts 0

Participants 2

I want to write a disk image (ISO, img) to an SD card, but I always get permission errno 13 (permission denied).

             let diskPath = "/dev/rdisk99"
            guard let diskHandle = FileHandle(forWritingAtPath: diskPath) else {
                throw NSError(domain: "DiskWriter", code: Int(errno), userInfo: [NSLocalizedDescriptionKey: "errno \(errno)"])
            }

It seems that when other macOS applications try to read from a raw block device it triggers an Access Removable Media prompt and when other applications try to write to a raw block device it triggers a Full Disk Access prompt.

How can I trigger that prompt? And then how do I elevate my write to use that permission?

P.S. I'm not a Swift coder, but I'd like to be... if it weren't that every "simple" thing I've tried launches me directly into a brick wall. :slight_smile: (not a criticism, just that the kinds of problems I like to solve tend towards uncommon and not as well supported in the ecosystem)

What I've tried

I did change Sandbox App to NO in MyApp.entitlements
I have tried manually adding my Debug Archive to Full Disk Access

Why?

As to why I'm I interested in this: Well, it just seems silly that UI tools that do what dd does are hundreds of megabytes. Can't we do this in a UI that uses all the default macOS libraries and is just a few kilobytes (or megabytes at worst)?

Boost

Answer 1

coolaj86 OP

4w

Update: notes to self:

looks like it may be a hacky-do of using a uri to open system preferences, polling until a known-inaccessible file becomes accessible, and then forking a call to authopen, dupilating a descriptor, and carrying on...
https://github.com/raspberrypi/rpi-imager/tree/qml/src/mac
https://github.com/MacPaw/PermissionsKit/blob/master/PermissionsKit/Private/FullDiskAccess/MPFullDiskAccessAuthorizer.m#L140

0

Answer 2

DTS Engineer OP

Apple

3w

Written by coolaj86 in 777577021

I'm not a Swift coder, but I'd like to be

Well, you’ve chosen a hard place to start |-:

I have a lot to say about this but I want to start by addressing two specific comments:

Written by coolaj86 in 777577021

I did change Sandbox App to NO in MyApp.entitlements

Don’t do that. If you don’t want to be sandboxed, remove the App Sandbox capability in the Signing & Capabilities editor. Setting the value to false can cause weird problems (although that’s unlikely to be causing problems for you here).

Written by coolaj86 in 830567022

using a uri to open system preferences

That URL scheme changed recently. I have links to docs for it in Supported URL Schemes.

Written by coolaj86 in 777577021

I always get permission errno 13 (permission denied).

macOS has multiple layers of file system permissions, and this error suggests you’re hitting the ur one, BSD privileges. If you were hitting a sandbox error or MAC error than that’d fail with error 1, EPERM. I have a bunch of info about this in On File System Permissions.

Another post that you’ll find useful is BSD Privilege Escalation on macOS. And I just updated it to account for authopen, which I’d completely forgotten about until you reminded me of it (-:

As explained in that post, there are a lot of ways you can approach this issue but the best approach depends on how you’re positioning your product. If you’re building an app for yourself, using AuthorizationExecuteWithPrivileges to run dd would be fine. OTOH, if you’re planning to distribute this widely, it would make sense to install a daemon using SMAppService and do the privileged work from there.

So, if you can explain more about how you plan to deploy this app, I’d be happy to offer more specific advice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

coolaj86 OP

3w

I tried commenting, but I wasn't allowed to do so (got a "null" error with "please try again"), so I'll try posting instead.

Thank you so much for this detailed reply. Right now this is just a weekend project for me, but given that there are 0 apps in the app store for this purpose, I'd like to pursue that path.

HOWEVER, if doing so requires having a background task with the "this program wants to make changes to your computer" as part of the install process, or "this program is running in the background" prompts at all, I think that will put off many people as it will sound unreasonable for the task at hand.

The way that the Raspberry Pi Imager works is inline with expectations - do a privileged thing, get asked to give privileges.

Asking to run a background service seems A) disrespectful of the installers computer and B) sketchy. If I had that experience, I would assume that the author is doing something underhanded and improper - not that they were simply doing something in a round about forced way to land an app in the app store. Even now that I know, that I would still be suspect and not want to use it.

0

	let diskPath = "/dev/rdisk99"
	guard let diskHandle = FileHandle(forWritingAtPath: diskPath) else {
	throw NSError(domain: "DiskWriter", code: Int(errno), userInfo: [NSLocalizedDescriptionKey: "errno \(errno)"])
	}