You do not have permission to open the application “Eclipse”.

I'm facing the same problem ...

See this

[https://stackoverflow.com/questions/68295434/facing-permission-related-issues-in-macbook-pro-with-big-sur-11-4)

I'm also facing the same issue.

Reinstalling the dmg works just for one day or less... Incredible, any solution @Apple?

Reinstalling the dmg works just for one day or less

OK, let’s start with some facts…

The system presents this alert when it’s unable to run the app’s main executable. For example, in one case I saw this on Apple silicon because the app was build for arm64e rather than arm64 [1]. The most common cause, however, is that the app’s code signature is broken.

And now we’re going to veer off into speculation…

My understanding is that Eclipse completely ignores Apple’s long-standing prohibition of self-modifying apps. I suspect that this issue has not been resolved in the intervening years, meaning that the app modifies itself and thus breaks its own code signature. It’s likely that this is triggering a problem within macOS’s trusted execution subsystem.

This would explain the behaviour you’re seeing. The app on the disk image is signed correctly, and so works immediately after you copy it off. Some time after that it modifies itself, which breaks the seal on the app’s code signature, and thus you see this problem.

And finally, a concrete test…

Try this:

1. Copy the app off the disk image.

2. Verify the code signature of that copy using:

   % codesign -v -vvv --deep /path/to/the.app
   

3. Run with that app.

4. When the problem rears its ugly head, repeat step 2. Does the signature still verify?

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

[1] Apple silicon Macs only support third-party arm64e for kernel extensions.

Could you elaborate on the step number 1? Is there any new solution to this? or has someone found any way to go around it? Need SpringtoolSuite4 for a college class.

The speculation from @eskimo was very insightful, after installing several plugins code sign does indeed show many modified files (and the application refuses to start). In my case this was due to installing plugins from the eclipse marketplace.

This does point the way towards an easier workaround:

1. Verify seal is broken:

   codesign -v -vvv --deep /Applications/Eclipse.app
   

   /Applications/Eclipse.app: invalid Info.plist (plist or signature have been modified)
   In architecture: x86_64
   

2. Sign the modified Eclipse.app

   % sudo codesign --force --sign -  /Applications/Eclipse.app
   

   /Applications/Eclipse.app: replacing existing signature
   

3. Verify seal is restored:

   % codesign -v -vvv --deep /Applications/Eclipse.app/Eclipse.app
   

   /Applications/Eclipse.app/Eclipse.app: valid on disk
   /Applications/Eclipse.app/Eclipse.app: satisfies its Designated Requirement
   

This is still a workaround, but beats reinstalling from scratch (and reinstalling eclipse plugins).

This is still a workaround

Right, and if you plan to use Eclipse in the long term you need to escalate this via their support channel. Their current approach, which involves modifying the app and thus breaking the seal on its code signature, is already causing problems, and this is likely to get worse in the future.

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

Just to add on:

I had to change something in the eclipse.ini, which is of course inside the package, that breaks the codesignature. But even better is that I run ABAP Development tools (better said JCo) and that plugin creates a log file inside the app package. So it breaks while starting ...