kappe_m, I had the same question back in the summer and got this work-around from an Apple rep: There is a workaround before the fix is implemented: To implement device access control for mass-storage devices based on e.g. USB serial numbers, ES clients can, before responding to mount events, query the IOKit registry for the service object corresponding to the disk device that is about to be mounted (IOBSDNameMatching). From there they can walk the registry tree to find the responsible USB device and query its properties (IORegistryEntryGetParentEntry, IORegistryEntryCreateCFProperties, IORegistryEntryGetChildIterator etc). Based on that information, they can make a policy decision and allow or deny the ES mount event. This is for USB mass storage events, not any USB device connection. Using the suggestions offered, I was able to get some proof-of-concept code working. Hope this helps.

The formatting got all messed up, best to just look at the header file in Xcode 12.2 beta 2 where I got this

From the header file /**Retains an esmessaget, returning a non-const pointer to the given esmessaget for compatibility with * existing code.* @warning It is invalid to attempt to write to the returned esmessaget, despite being non-const, and * doing so will result in a crash.* @deprecated Use esretainmessage to retain a message. *@param msg The message to be retained * @return non-const pointer to the retained esmessaget.* @brief The caller must release the memory with es_free_message/OSEXPORT APIDEPRECATED("Use esretainmessage to retain a message.", macos(10.15, 11.0)) APIUNAVAILABLE(ios, tvos, watchos) esmessaget * Nullable escopymessage(const esmessaget * _Nonnull msg);

It's the way that the process are launched that is confusing. Here is the explanation from Apple PIDs are assigned at fork time, not exec time. When the ES kext knows there are early boot clients, it holds up the kernel thread performing the execve. So all binaries that would get exec'd (e.g. via Loginwindow, launchd loads, etc.), will all get a new pid - they just won't have code execute if they're non-platform binaries until the ES client connects and makes its first set of subscriptions (and, if they subscribed to AUTH EXEC, the client has the opportunity to DENY the exec from continuing). None of this has anything to do with lower numbered PIDs. I did prove that this was the case by looking at log lines from my extension and my launchd process. The extension logged first, even though its PID was larger.

Sorry for the late reply, been super busy. Yes, I was seeing the same thing, launchd agent failing to connect at startup, until I did the early boot. Then I saw PIDs that didn't make sense, but looking at timestamps of messages I added, I saw that the system extension loaded and ran before the launchd process. This was the comment I got back from Apple when I asked back in April: PIDs are assigned at fork time, not exec time. When the ES kext knows there are early boot clients, it holds up the kernel thread performing the execve. So all binaries that would get exec'd (e.g. via Loginwindow, launchd loads, etc.), will all get a new pid - they just won't have code execute if they're non-platform binaries until the ES client connects and makes its first set of subscriptions (and, if they subscribed to AUTH EXEC, the client has the opportunity to DENY the exec from continuing). None of this has anything to do with lower numbered PIDs.

I had the same question a while ago. Even though a launchd app has a smaller PID than your system extension, the launchd app is blocked from running until the early boot extensions load. I confirmed this with log messages at startup in each and saw the timestamps.

This is from the release notes (not sure which release) and I don't know if it's still true: Moving a kernel extension bundle out of /Library/Extensions might not completely uninstall it. (64331929 Workaround: Remove the extension from /Library/Extensions. Boot to macOS Recovery. Run Terminal. Enter the command kmutil invoke-panic-medic. Restart your Mac. Follow the prompt to open System Preferences and navigate to Security & Privacy. Follow the prompt to restart.

I don't know if this is the same situation I had early on, but when I was in the compile/link/install/run/uninstall/repeat loop, if I didn't reboot after the uninstall, that removal would queue up. After half a dozen or so loops, I'd have a list of extensions ready to uninstall on reboot. I'd reboot and one would be gone, reboot again and another would be gone. I'd have to keep rebooting to get rid of them one by one. Like I said, this was a while ago and I've gotten into a habit of either restarting the VM or restoring the snapshot. Not sure if this is what you're seeing or not.

Well, the Forums are now broken. Search only works if you know what you're looking for. Browse is the way to find new things you didn't know about.

Glad I could help

I think that is a ES_EVENT_TYPE_AUTH_RENAME event. I don't have anything setup right now to verify this, but if you think about how you'd do it from a command line, you'd use a mv command to either rename the file or move it to another location, i.e., the trashE.g., my code has this in the rename event handler if (msg->event.rename.destination_type == ES_DESTINATION_TYPE_NEW_PATH)We're checking to see if there's a new path. Just look to see if someone is moving the file you care about somewhere else.

Thanks, Quinn. I actually got a response back from our Apple rep who said that since we're not MAS, we can make the NE unsandboxed and it should work.I'll let you know how it goes when I get there, fighting another fire at the moment.

Hi Quinn,Does this imply that you cannot have both an ES and NE solution in one binary that can be delivered to our customers? Our controlling app assumes one connection to the driver and will be unpleasant to rewrite the comm part for macOS only.Thanks

I don't know if that's the only answer, but it's what I've found by reading the forums and experimentation. If you, or anyone, finds some definitive documention, please post a link here. I'd love to read it and let our support team know when we release our product into the wild.

What I've found is that you need to keep rebooting, they disappear one at a time and not all at once. If I forget to do a snapshot of my VM before a day of testing, I've found myself just sitting there at lunch restarting, time after time, until they're gone, just to make sure I have clean slate.