Permission errors within an app after updating from MacOS 14.0 to 14.1

I talk about these errors in On File System Permissions. That suggests that:

• Your SMB share access is being denied by either the App Sandbox or MAC.

• Your spawning of a child process is being blocked by BSD permissions.

However, it’s hard to be sure without more info. Let’s start with the second issue, because those problems are usually easier to resolve. How are you trying to spawn that child process? Using Process (NSTask in C-based languages)? Or fork / exec*? Or posix_spawn? Or something else?

Could it be that the app is sandboxed by default on MacOS 14.1?

That seems unlikely, but if you want to know whether an app is sandboxed you can view that in Activity Monitor. Control click on the process table header to enable the Sandbox column.

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

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.

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.

You wrote:

It is an python script and not a binary thus python3 /usr/local/bin/ip works.

Scripts and TCC are problematic, because you have to grant the privilege to the interpreter. There’s no way to grant a privilege to the script itself.

It is important for us to find a way that does not involve manual user interaction.

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.

Regarding the Permission Denied on the ip call: /usr/local/bin/ip has the access settings rw-r--r--

In the terms defined by On File System Permissions, those are traditional BSD permissions. That’s not the cause of this issue.

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

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?

An update on our situation: With the latest macos patches, this seems to affect not only macos 14 but other (all?) macos versions as well. We have a service running as LaunchDaemon. This service can mount a network share and access it without any problems. When this service creates a subprocess, this subprocess cannot access the network share mounted by the parent. Even the subprocess "cat <share>/<somefile>" fails with "Operation not permitted" - apparently rejected by MAC. A few weeks ago that was not a problem.

If i grant "Full Disk Access" to the parent process, the child can access the share alright.

1. Is there a way to make this work without having to set Full Disk Access? A specific mount point location or flag to set? Previously we worked with the home directory /var/opsisetupadmin of a user specifically created for this purpose.

2. If it really would be necessary to set Full Disk Access, is there a way to initiate this through a command? I understand that you want to have manual user interaction involved. But is there a way to simply prompt the user to allow access, without them having to manually go through system settings?