Is there anything in common for all the things installed in /Library/Apple/ ? I seem to see things related to malware detection and removal, and things like that... Is there a better description for what's in there? The directory structure of MacOS becomes more and more frustrating, and there is no coherent source for learning about it.

Thanks. I now spot a typo in my suggested code, where I used the wrong tv_sec twice - both for seconds since 1970 and for the nanosecond part. should be tv_nsec instead for nanoseconds. Also instead of dividing directly by 1e9 I could use the nicer NSEC_PER_SEC definition for clarity. Would fix that in the question, but I can't see a way to edit my old question now.

I think the C API allows for bi-directional messaging, whereas NSXPCConnection is (to my best understanding) one-way. Also NSXPCConnection implementation only supports very limited set of Foundation classes you can send as arguments in XPC messages, whereas the C API allows encoding almost anything. I think the control is also more fine-grained, but I may be wrong. BTW - the question is "can LaunchAgent publish XPC service" ? in which domain?

For the record, here is the feedback ID of my official request: FB10027841 It contains more or less the same description as in my question here - please review and let me know If something important is missing from my description

Thanks a lot for your answer. I dreaded it will be like that... In my situation, I think linking in libmagic (I still need to understand how, and where to get its code from) could serve me best, since the magic database isn't really changing format so often, while our product is bound to regularly evolve and be released. I believe Apple database is much better than anything I could come up with. Is libmagic part of Darwin? Is it different than the several open source versions I can find in GitHub, SourceForge.net openhub etc.? Another question (regarding the 'file' command). Is there a way to "wrap" an instance of 'file' as a daemon, regularly receiving input via stdin, and emitting its result to stdout, sparing the need to spawn it again and again? That may be slower than directly using libmagic, but bound to be much faster than spawning NSTask for every file identified. I'm not a unix wiz, so I don't know what's available to me in that respect.

I already went so far as to not-find the libmagic (or its headers, or its similarly-named filemagic friend) and I think the reason is different - I think MacOS uses a different 'magic' format, probably more powerful, as it can identify quite complicated files, and also minor version differences in these file formats - it may be that the implementation is completely different. Also Apple states the '.mgc' file is "compiled" (it is by all means 'binary' file) which also makes me think it is something proprietary. That's why I'm asking for an API... I know it wouldn't be easy to mimic this myself, or even read that magic file.

So.... if that call isn't available to us mere NSXPCConnection users, what could we do instead? I'm verifyng caller at the - (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection; level, identifying the caller by PID, but every once in a while         NSDictionary *attributes = @{(__bridge NSString *)kSecGuestAttributePid : @(clientPID) };         OSStatus status = SecCodeCopyGuestWithAttributes(NULL, (__bridge CFDictionaryRef)attributes, kSecCSDefaultFlags, &dynamicCode); crashes my XPC Service, with nice stack somewhere deep in SecCodeCopyGuestWithAttributes: ` 0 libsystem_kernel.dylib 0x183dcd9b8 __pthread_kill + 8 1 libsystem_pthread.dylib 0x183e0115c pthread_kill + 288 2 libsystem_c.dylib 0x183d3e314 abort + 164 3 libsystem_malloc.dylib 0x183c23a1c malloc_vreport + 552 4 libsystem_malloc.dylib 0x183c38c8c malloc_zone_error + 104 5 libsystem_malloc.dylib 0x183c15db0 nanov2_allocate_from_block + 568 6 libsystem_malloc.dylib 0x183c153a4 nanov2_allocate + 128 7 libsystem_malloc.dylib 0x183c152c0 nanov2_malloc + 64 8 libsystem_malloc.dylib 0x183c32770 _malloc_zone_malloc + 156 9 CoreFoundation 0x183e5ab0c resolveAbsoluteURLStringBuffer + 1012 10 CoreFoundation 0x183e5a678 resolveAbsoluteURLString + 188 11 CoreFoundation 0x183e58744 CFURLCopyAbsoluteURL + 568 12 CoreFoundation 0x183f6f750 _CFURLCreateWithFileSystemPath + 2236 13 CoreFoundation 0x183eb874c _CFBundleCopyExecutableURLRaw + 320 14 CoreFoundation 0x183eb84e0 _CFBundleCopyExecutableURLInDirectory2 + 452 15 CoreFoundation 0x183f37ff0 _CFBundleCreateWithExecutableURLIfLooksLikeBundle + 128 16 CoreFoundation 0x183f37f24 _CFBundleCreateWithExecutableURLIfMightBeBundle + 20 17 Security 0x1860d3d18 Security::CodeSigning::KernelCode::identifyGuest(Security::CodeSigning::SecCode*, __CFData const**) + 544 18 Security 0x1860ab040 Security::CodeSigning::SecCode::identify() + 96 19 Security 0x1860ab8c0 Security::CodeSigning::SecCode::autoLocateGuest(__CFDictionary const*, unsigned int) + 188 20 Security 0x1860b2318 SecCodeCopyGuestWithAttributes + 144 21 xpcj 0x11706c3b0 -[OITContentScanningXPCService listener:shouldAcceptNewConnection:] + 556 (OITContentScanningXPCService.m:209) 22 Foundation 0x184e274c8 ` So... how to go about this, and is it better to use the kSecGuestAttributeAudit instead of the kSecGuestAttributePid when calling SecCodeCopyGuestWithAttributes ?

Thanks, but NSNotificationCenter is both deprecated, and does not provide some of the features I need. I resorted to the cumbersome combination of LaunchAgent and a menu-bar-app, negotiating via XPC. So when my LaunchAgent wants to notify user, it sends an XPC call to the menu-bar app, which in turn creates and dispatches a UNNotification. It IS cumbersome and ugly and requires maintenance and a whole mechanism of launching/updating/quitting the menu-bar-app, not to mention the mach-service XPC listener in my LaunchAgent and so on. Please be kind and notify here if Apple takes it to improve UNNotificationCenter to use "signature" of a binary, in cases where a code-bundle isn't available. After all the reason to have LaunchAgents - is to have UI for a background daemon.

No I did not find a way, and last I created a little "menu-bar app" with that tiny icon, that my launch-agent launches when it needs to communicate with user, and via XPC I direct the information to that app, which in turn creates the local notifications using UNNotificationCenter. I could not use the older NSNotificationCenter, because I need many of the newer features of UNNotificationCenter (coalescing and grouping user notifications, customizing their UI, adding user-options etc.) The important thing is, when you "click" a notification in the user-notification-center, MacOS launches the App that created and sent that notification - and sends it a delegate call with lots of information, to continue the dialog with the User. A LaunchAgent like mine, has very dull UI and most of the time it doesn't "remember" a user's state. Anyway, one thing I did test with - and didn't work as well - was to apply a "bundleId" directly to the binary - something I didn't know existed before, but Xcode knows to do that. So a single binary agent/daemon CAN have a "signature" of the "com.mycompany.myagent" type. UNNotificationCenter doesn't respect that signature though.

Or, for a small effort, build your own command-line binary (say using swift or Objective-C) to call just that...

And another issue with that approach is, sometimes good user interface dictates SILENT failure attempting to open a file, and SPECIFIC timing for asking the user for permissions. For this - knowing in advance whether or not app/process has "full disk access" granted - is needed (I think - required).

In my case, there's a "product requirement" to be able to work and fail "silently" when we don't have full-disk-access (depending on some remote customer configuration). So we NEED to know in advance, whether reading some files is going to fail. In the "silent" mode, we do NOT want MacOS to pop up any alerts to the user and distract them. We'd rather do it sometime else, later, e.g. on next launch or so. I'm not the OP and my needs are different, plus my product isn't "App" (rather a global Agent) which makes this requirement reasonable. User doesn't expect IT security background agents to pop requirements for disk access... We do have UI, but we present it in very small set of situations, controlled precisely by customer configuration. So the question remains: How do I know whether or not my process has "Full Disk Access" ? Other TCC entities (like Accessibility for instance) provide such APIs to query TCC for permissions.

As always, you ARE a life saver. Thank you very much. Will hold this doc close to my heart for years to come.

Explanation. Our current product structure is similar to many "linux style" deployments - a bunch of binaries sprawled all over the place - /etc /tmp and the like, with cumbersome shell scripts for installers and lots of "config" files everywhere... not even a bundle that can be code-signed as a whole. All TCC handling is clunky because I don't even have a "bundle ID" for components to rely on - just paths. What I'd like to do (and did in the past for other employer) is to restructure all components into a single bundle (back then, I made it a "Preferences Panel" with minimal UI), with all the deploymeny (dynamic libraries, private frameworks, daemons, agents, resources and so on) within the bundle. Then - code-signing, installation and removal are a breeze, tempering with the product is harder, and most important - integration with the "Mac" world of APIs (generally Cocoa but other things too) is far more effective (I just HATE config files. UserDefaults are KVO compliant, and maintain much better, and...) well. In that respect, I'd like to have this Java-written "service" be an XPC-Service available to other components WITHIN its bundle. Is this possible?

Who said that MacOS development should be generally case-insensitive?