tried a different approach by sending an open file handle via XPC to the extension hosting app and then tried to use fgetxattr() on that file handle. This only works with SIP disabled. With SIP enabled, the hosting app also needs full disk access but then reading the extended attributes succeeds. What are the current security implications by sending file handles via XPC in a SIP-enabled environment from a root system extension to user launched app? Frank

Hello, here's a brief outline of the architecture in use. [daemon app] running as root with Full Disk Access enabled. -> is linked against PyHelper.framework located in /Library/Frameworks -> calls PythonHelper() (passes python byte code) [PythonHelper() function]-> loads PyExec.framework via dlopen() also located in /Library/Frameworks PyExec.framework has a customized version of Python located in Version/Current/Frameworks/Python.framework -> gets PythonExec() function via dlsym() which finally causes the embedded Python framework to execute the byte code -> file deletions at this level fails! No new process is created! Frameworks and calling daemon app have the same code signing and team ID. This architecture works on 10.15 but breaks on Big Sur. I've tried even with SIP disabled which does not result in a different outcome. Frank

so, on macOS 10.15 our daemon process uses a framework in /Library/Frameworks to do file operations, for example deleting a file. This is done via a customized version of Python within the framework. In order to access files on the whole file system, we just had to add the daemon app bundle to the "Full Disk Access" privilege list and functions passed to the version of Python embedded in the framework could delete files. on macOS Big Sur this does no longer work. The daemon app is still added to the "Full Disk Access" list but the functions within the framework can no longer delete files. Enabling hardened runtime on the daemon process did not help. Do frameworks need special attention in regards of full disk access? Frank