Full Disk Access and Frameworks on Big Sur

Under 10.15 it was enough to give the as root running App Full Disk
Access rights to the function within the framework so it was able to
delete files.

I’m sorry but I can’t parse this sentence. Can you clarify?

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

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

Do you execute the Python code by firing up the Python runtime within your daemon process? Or by running Python in a separate process?

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

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

Code Block 
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

Not solved, accidentally clicked..

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.

Why not just delete the files? Why go through Python?

Full Disk Access is tricky. If I understand your description, I'm surprised it worked in Catalina. I have an app that uses Full Disk Access and launches a helper tool to analyze hard drive storage. I used to have option to run the helper as root if the user wanted that. But there was some funky behaviour between a root-owned process being run from a user space process with Full Disk Access. In short, Full Disk Access simply didn't work in that configuration. I even tried giving the helper Full Disk Access, but it didn't work.

In my case, I didn't really need root, just I just omit that option on Catalina and later.

I'm afraid I don't have a good solution for you. You could get rid of the Python stuff, or maybe add yet another helper to do the deletion from an agent in user space. You can just pass the paths and then put the user in charge of deleting the files, via a script or similar.