Setting --disable-seccomp-filter-sandbox by default on Linux?

It seems like a recent system update in openSUSE Tumbleweed has caused the built-in Qt web view to not like working with the default seccomp filter in Anki.

No doubt this is some kind of upstream library bug, but give that it renders Anki completely unusable (pretty much every screen is blank and doesn’t render at all) maybe it would be a good idea to disable the seccomp filter sandbox within Anki if starting on Linux? It technically will reduce the security hardening of the built-in web viewer but finding out that you had to set QTWEBENGINE_CHROMIUM_FLAGS="--disable-seccomp-filter-sandbox" in order to work around this problem was a bit tricky, and it means that I cannot start Anki from my normal launcher (instead I have to launch it from the terminal each time). However the fact that there were other Anki bugs with similar symptoms seems to suggest to me it wouldn’t be a bad idea to make this a bit easier to work around when it happens.

1 Like

Are other QtWebengine apps still working, or have OpenSUSE broken WebEngine across the board? While I want things to “just work”, I’m not sure we can justify turning off a security feature for all Linux users just to work around issues with one distro.

Doesn’t Anki use its own packaged version of QtWebEngine? I tried using qml on a basic QML file and it works without issue under openSUSE:

import QtQuick 2.0
import QtWebEngine 1.0
import QtQuick.Window 2.0

WebEngineView {
  width: Screen.width
  height: Screen.height
  url: 'http://duckduckgo.com'
}

And it works without needing any special flags. So it seems the issue is with the packaged version of QtWebEngine used by Anki? I suspect the issue is the openSUSE updated to glibc 2.34 quite early, meaning that whatever seccomp profile Qt uses probably doesn’t include all of the syscalls necessary for glibc to function (bit strange that this doesn’t cause Anki to crash but :man_shrugging:).

Yup, it’s because of glibc. Looking at the strace logs, glibc is trying to use clone3 but the seccomp filter is blocking it:

18656 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EPERM, si_call_addr=0x7fc4d3b5a7fd, si_syscall=__NR_clone3, si_arch=AUDIT_ARCH_X86_64} ---

It seems that the version of QtWebEngine used by Anki needs to be updated. There is a Qt bug report for this issue.

also discussed e.g. here.

in the meantime the anki version from flathub should work - internally it seems to use glibc version 2.31 and I just tested on Fedora 35 that also uses glibc 2.34: When running the anki binary directly all my webviews are empty whereas running the flatpak version works.

I’m referring to: Flathub—An app store and build service for Linux

The anki flatpak isn’t built from source instead it just bundles/wraps the binary from apps.ankiweb.net. If you want a newer Anki version (or an Anki version that was never uploadd to flathub) as a flatpak you can build it yourself basically by changing the app-id and source in this template. You can also export your custom built flatpaks and share them without relying on flathub. You need one command to build the new local flatpak, one command to export it as a shareable file and one command to install this on the other computer.

 

Would disabling the sandbox for new Anki versions really help much? Hopefully the next Anki will be based on qt6.2 which should have a fix for this (?). The real problem seems to be that older and popular Anki releases like 2.1.44 or 2.1.35 no longer just work on these newer distro releases. The only way to make the older anki versions run out of the box should be an alternate re-release for these old versions?

1 Like

The solution suggested in the original topic was before I figured out what was going on. Updating Qt is a better solution, and assuming that is coming for the next release, I’m happy to continue disabling seccomp manually until the next release.

I believe it’s fixed in Qt 6.2. They fixed it in 5.15 as well, but only provided an updated binary build to their commercial customers.