Core dump on new install

Support
1

Operating system

Linux

Joplin version

3.3.13

Desktop version info

Wish I could.

Sync target

Nextcloud

Editor

Markdown Editor

What issue do you have?

I can't run Joplin on KDE Neon. I just installed it with the install script to give it a run, and its no show.

Try to start it, the icon pops into the task bar and then vanishes.

Look in the logs and its core dumping.

Run it from the command line and I get
[348954:0610/131548.717463:FATAL:setuid_sandbox_host.cc(163)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_JoplinX6Ejym/chrome-sandbox is owned by root
and has mode 4755.
fish: Job 1, './Joplin.AppImage' terminated by signal SIGTRAP (Trace or breakpoint trap)

Seems she's broken.

2

You could start it with the --no-sandbox flag, as suggested in this thread

3

OK, thanks @Marph, but I'm not sure that's a good answer. The whole point of appimages is for the sandboxing.

4

I'm not certain, but I guess then you have to wait for Electron/Apparmor to resolve the issue. Some background information and further links are provided at this Github issue (taken from the forum thread above):

1 Like
5

The only thing Electron can do is disable the (unprivileged) user name spaces component of their sandbox (preferably specifically, it's not super clear to me what other components --no-sandbox disables, but there are other sandbox related flags so it's not as binary as the name suggests), by every other respect this is a packaging problem and the only "fix" is a package without the problem. By Joplin officially, that'd be the .deb which doesn't need --no-sandbox because instead Joplin briefly runs as root and drops the root permissions once it's set up the other components (chromium-sandbox has a SUID bit and is owned by root, meaning anything that runs it, runs it as root).

Debian doesn't have this functionality by default, Ubuntu has it but in a more restricted mode where AppArmor mediates it so some software can use it, I think RHEL doesn't come with this enabled by default since I remember having to enable it there to get e.g., Flatpaks to work, I could be wrong on this though since RHEL10 comes with Flatpaks by default, this was super specifically CentOS 7 at the time.

(

In a default or common use of Red Hat Enterprise Linux 7 unprivileged user namespaces are disabled by default, so local unprivileged users cannot abuse namespaces to grant themselves the CAP_NET_RAW capability and potentially elevate their privileges on the system.

)

Linus Torvalds himself has said that he doesn't like the API being used by unprivileged processes and considers it a mistake they're stuck with, so although appeal to authority isn't a solid logical paradigm, the authorities seem pretty consistent on this.

If a user disagrees, then they can re-enable the API, but it's disabled as a distribution policy, not a bug, Ubuntu knew what they were doing when they made this decision, as did RHEL.

Of course, Google only care about Chrome, which also installs as a native package without this problem, so it's difficult to expect progress when the people leading the underlying framework don't have a reason to care.

Regarding this specifically, AppImages are unsandboxed unless you use external tools like Firejail or similar to change that. No AppImage has sandboxing by default, Joplin or otherwise, the sandbox is specific to the Electron parts to defend against specific web exploits; the app itself is free to delete all your files if it wanted to though.

6

OK.. thanks for the detailed response @james-carroll. I'll give it a go without the sandbox and see what happens :). Pretty sure its not going to hose my system anyway.

Thanks again.

7

Just incase you wanted the sandbox anyway, since I didn't write it in the previous post.

echo 'kernel.apparmor_restrict_unprivileged_userns = 0' | sudo tee /etc/sysctl.d/20-apparmor_restrict_unprivileged_userns.conf

Followed by a reboot.

If my above post seemed quite doomer, I'll be clear and say that I don't personally think your personal security is likely to be impacted by re-enabling the API the sandbox uses to avoid needing sudo. IMO the context of these protections is far more closely associated with e.g., environments where people might upload untrusted code to other computers (like public clouds, or high performance computing clusters - Ubuntu has a heavy server presence in these kind of environments), and not environments like a home user where they're hopefully not running untrusted code on the regular, and should they be, there's worse problems already.

It helps that Joplin primarily only runs its own code. While you can e.g., use the WebClipper to embed websites you browse, then, you've already browsed the website in another browser that's likely already being attacked if there is maliciousness involved, on top of there being an explicit user request to do so to get it into Joplin. I can't think of situations where Joplin is exposed to legitimate untrusted code without user interaction, with my sandbox hat on, that's not to say every little helps, but ultimately it's a personal choice for yourself and the reality is there's not much in it either way for a home user, but you could argue you're slightly more likely to be exposed to the Electron type threats than the "I compete with Microsoft in selling Virtual Machines" type threats.

1 Like