Single Local Network permission entry shown for different applications

I have two applications (MinimServer and MinimWatch) that run on macOS. Both use the local network.

On Sequoia, starting MinimWatch for the very first time after installing Sequoia shows a prompt for permission to access the local network. If the user agrees, an enabled entry for MinimWatch appears in the Privacy & Security > Local Network section as expected.

If MinimServer is then started for the very first time, there is no prompt and the existing Local Network entry for MinimWatch now controls local network access for both MinimWatch and MinimServer.

If ths above order is reversed (start MinimServer first after installing Sequoia and then start MinimWatch), Local Network shows a single entry for MinimServer which controls network access for both MinimServer and MinimWatch.

It appears there is a false positive match when the second application is started. Sequoia finds the Local Network entry for the first application and incorrectly idenfies this as matching the second application.

Both applications are written in Java and have a similar internal structure. The app packages contain some identical files but the following files are different:

  1. The bundle executable in the MacOS folder
  2. Other executables in the MacOS folder launched by the bundle executable
  3. The Info.plist keys CFBundleName, CFBundleIdentifier, CFBundleExecutable, CFBundleIconFile and JVMMainJarName

What might be the similarity between these app packages that is causing Sequoia to incorrectly identify one of these applications as being the other application?

Answered by DTS Engineer in 808817022

Oh, hey, do I have the technote for you!

Well, actually, let’s start you off with this DevForums post: On File System Permissions. In there I explain how apps need a native main executable in order to play well with TCC. It’s very common for Java apps to use a shell script as their main executable, and thus encounter weird TCC problems.

Beyond that, for local network privacy specifically, this main executable needs to have a unique bundle UUID. See TN3178 Checking for and resolving build UUID problems.

Share and Enjoy

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

Accepted Answer

Oh, hey, do I have the technote for you!

Well, actually, let’s start you off with this DevForums post: On File System Permissions. In there I explain how apps need a native main executable in order to play well with TCC. It’s very common for Java apps to use a shell script as their main executable, and thus encounter weird TCC problems.

Beyond that, for local network privacy specifically, this main executable needs to have a unique bundle UUID. See TN3178 Checking for and resolving build UUID problems.

Share and Enjoy

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

Thanks very much for your prompt and very helpful reply.

Both apps have a native main executable, so that wasn't the issue. Your pointer to the need for a unique bundle ID led me to the cause of the problem: an error in my build script had caused the main executables in both apps to have the same bundle ID. When I fixed the build script, everythng started to work as expected.

Single Local Network permission entry shown for different applications
 
 
Q