[Software] Java app forbidden to run. Why, and how do I regain control of what apps are allowed to run on my kubuntu desktop?

[DinoNerd]

I upgraded from 25.10 to 26.04 LTS some months ago.

While on 25.10, I installed and ran a java app. It ran, but not usefully, because it couldn't handle Wayland's fractional scaling, which was set up on this system by the default Kubuntu installer. My research failed to find a solution to the problem beyond "wait a few years", so I chose to use the app on an elderly Macintosh, where I didn't have to contend with Wayland.

When 26.04 LTS came out, I upgraded the system to it, but didn't attempt to run the problem app.

Months later, an online discussion suggested to me that this toggle on the Display and Monitor section of the System Settings App might solve the problem, by interposing XWayland between the app and Wayland itself.



Today I tried it, then launched the app from the command line.

I got this:



As you can see, there's no explanation of the security problem or any identification of the piece of software whose authors have determined that Kubuntu users are to be forbidden to use java, or perhaps this app, or perhaps just whatever version of java I have installed.

Given that all the .debs on my system get upgraded at the same time, the "insecure" java is presumably the same release/bug fix generation as this vigilant if uncommunicative sentry, protecting me from risks it doesn't care to explain.

Or maybe not - part of kubuntu comes as snaps, rather than .debs, and since I've no clue what software issued this message, I can hardly guess how its distributed.

--
I'm feeling very cranky right now. I have strategies I can use to identify the blocker, and maybe even find out what the undescribed security issue might be.

But I don't want to apply them as much as I want to find whoever broke my system by implementing this, and yell at them for the next several hours.

I'd also like to know how this got onto my system. Apple has a back door whereby they can push what they consider to be urgent security fixes onto internet-connected Macs that are refusing OS and app updates. It's not clear whether the user will even know they've had their software changed. Does Kubuntu have something similar?

Or did I get this via (a) upgrading to 26.04 or (b) doing "sudo apt full-upgrade" ?

[claydoh]

Try starting it directly using java -jar to make sure it is actually working properly

java -jar /home/arlie/games/haven/ender_beta/launcher-hafen-beta.jar
​

You may be having the same issues others are having, and not specific to Ubuntu Resolute
https://forums.linuxmint.com/viewtopic.php?t=471375

https://bugs.launchpad.net/ubuntu/+s...~:text=9-,This

https://bugs.launchpad.net/ubuntu/+s...5/+bug/2160679


Now, if you don't want to use the terminal or a script to run this command, you *might* edit a line in /usr/share/applications/openjdk-25-java.desktop ( it might be a different number for you; 21 and 25 are common)

Edit it in kate or Kwrite

Exec=cautious-launcher %f /usr/bin/java -jar

to be

Exec=/usr/bin/java -jar

And save

This might be a security risk, and afaik is not related to Wayland or anything at all here.

[DinoNerd]

Try starting it directly using java -jar to make sure it is actually working properly

Whoops.

This turned out to be the problem, and it probably isn't new.

I'm about 60% sure I've seen this before, and learned to work around it months ago when I couldn't get the java app to work correctly.

I'd merely forgotten about it.

---

Now, if you don't want to use the terminal or a script to run this command, you *might* edit a line in /usr/share/applications/openjdk-25-java.desktop ( it might be a different number for you; 21 and 25 are common)

Thank you. Once I digested the first part of the above, and realized my mistake, I started thinking of workarounds, since I fear I won't tend to remember to include the -jar Yours will be less trouble than writing a shell script, as I'd need a script for every java app packaged as a jar.

--

FWIW, the MacOS file manager will do the right thing if you double-click on such a file, rather than throwing a confusing error message.

[DinoNerd]

This might be a security risk

I've been reading CVE-2026-10037 (Thanks for the links that gave me the CVE number.)

The security risk involves a potential sandbox escape.

Given the complexity of any linux distro, and K/Ubuntu in particular, I simply do not know whether there are any sandboxed apps on my Kubuntu system.

I suspect that Snap (and Flatpak) are built on top of some kind of sandbox technology.

There's also a level of sandboxing, of sorts, implicit in the namespace functionality in the linux kernel.

But of course if there's malicious code built into the distribution this particular exploit hardly matters.

I'm not running untrusted apps in virtual machines or containers. So I'm probably safe to neuter the sandbox escape mechanism.

--

But the truth is, I don't understand what I'm reading in CVE-2026-10037. I wouldn't know the OpenURI portal or xdg-desktop-portal-gtk if they jumped out of the computer and bit me.

However, the fix is reminiscent of the sort of kludges once used to handle security problems with executable shell scripts. That long standing issue was only fixed when #! lines in shell scripts were handled inside the exec system call, deep in the kernel. That finally allowed a real fix. (Yes, this was probably before many posters here were born. I'm old.)

The cases aren't otherwise similar, and I don't in any case understand this bug. It just feels as if xdg-desktop-portal-gtk must by bypassing sandboxing, rather than in effect executing within sandbox limitations. Otherwise it wouldn't need a fix of this type.

But if I'm right, the security issue will probably reappear in a new guise, in spite of the change that was made.

[claydoh]

One of the two bug reports notes that the fix breaks things not involved, but no idea of the fix.

The general lack of complaints seems to indicate that most people are running the apps using the time-tested java -jar /path/to/jar method normally. Probably because just clicking the file has never ever consistently worked as expected for as long as I have been Linux-ing, and java being, well, java.