Why is that? One goal of TCC is transparency, that is, users should know what programs are doing. We only support bypassing that in limited circumstances, for example, in a managed environment. Because this software is part of a client management system to manage computers. The goal is to have no further need of interactions by any user after our tool was installed. The tool also installs the app, mounts a share to which the app needs access and finally runs the app. The installation of the tool was triggered by our software, on demand of an administrator. However from an admin's perspective it is not a good idea if he/she has to confirm manually full disk access for the tool on hundreds or even thousends of client computers. That is why we need the ability to allow full disk acces for the tool without any further user interaction. So is there any possibility to do that? Or do we/our customers have to use Apples MDM system for that purpose?

It is important for us to find a way that does not involve manual user interaction. Could you give us a hint on a good mount point location so that a child process of the process that mounted the share can access it without requiring the "Full Disk Access" right? Regarding the Permission Denied on the ip call: /usr/local/bin/ip has the access settings rw-r--r-- so that not even root can execute it. Im not sure if this is intended.

Thank you for your reply! The app is not sandboxed, the SMB share access was probably blocked by MAC. The tool which mounts the share also executes the app. If giving the tool full disk access it works, I guess because this is inherited to the child process. We also solved the permission denied problem for the ip command. It is an python script and not a binary thus python3 /usr/local/bin/ip works.