Full Disk access to launchctl script

Question

lundman OP

Created Feb ’20

Replies 3

Boosts 1

Views 2.7k

Participants 3

Part of the install of our kext is a simple launchctl script to automatically mount the volumes.

<key>ProgramArguments</key>

<array>

<string>/usr/local/libexec/zfs/launchd.d/zpool-import-all.sh</string>

</array>

<key>RunAtLoad</key>

In essence, the script is:

#!/bin/bash

/usr/local/sbin/zpool import -a

If users add "bash" to allow Full Disk access, the script runs on boot. So that's "a" solution.

But allowing "bash" Full Disk access is an excessively large hammer I feel.

However, allowing "Full Disk" access to "zpool" will not work, it is

apparently not enough.

In the interest of doing things the way Apple intended (or rather, not going against Apple) what would

be the "right" way to approach this. Clearly there is some inheritance in play, but it isn't clear to me

how that works. Why wouldn't allowing "zpool" to work? How to debug this?

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’20

What file operation is failing when you don’t have Full Disk Access?

Is

zpool

code signed in a consistent manner? That is, signed using a code signing identity issued by Apple such that its designated requirement is stable between runs?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

lundman OP

Feb ’20

zpool binary, and all its .dylibs, are signed and notarized. Hopefully correctly, but let's leave a little room for the possibility I got something wrong.

I need to think up a good way to test the issue, since it appears to trigger at boot (when it is supposed to import the pools), from launchd. I believe when run by hand after a user logged in, all is well. Could it be running too early, before the OS has a chance to verify certificates?

I found I had to leave "mount_zfs" unsigned for mount_root - or it would fail to mount root at boot time as it was unable to verify the teamID. But that is unrelated I think.

0

Answer 3

john daniel OP

Feb ’20

I think you've got too many things going on at once. I suggest dealing with them one at a time.

1) You are trying to run a shell script through launchctl. You can make that work, but there is no point in relying on all the shell script baggage when you don't need to. Instead, use this in your plist:

<key>ProgramArguments</key>

<array>

<string>/usr/local/sbin/zpool</string>

<string>import</string>

</array>

If this fails, it means you are relying on some shell script baggage like environment variables. Ideally, remove that baggage or maybe configure your plist to provide what you need. Also, never use an interactive shell like "bash" as an unattended interpreter. Just use "sh" for these situtations. And don't use bash at all on a Mac. It is long since deprecated and dead-in-the-water. Use zsh if you want something modern.

2. Maybe there is no 2). The above might solve the problem. If it works form the command line but not in launchd, that is usually a classic launchd problem and unrelated to any new permissions issues.

3. Regarding Full Disk Access. What are you trying to do here? Clearly it is something with zfs. But Full Disk Access, especially in this context, shouldn't be required. Full Disk Access, especially in a non-sandboxed, root context, only protects certain sensitive Apple directories and certain user directories. If you are mounting new zfs volumes, it shouldn't have anything to do with Full Disk Access.

0