Sandboxed qtwebengine crashes
CL version 40250. KMail installed through the desktop-kde-apps bundle.
When selecting any mail from the list the content of that mail isn't shown in the preview area. Double clicking it opens a window but the mail contants aren't shown either. Switching between plain text and HTML view makes no difference.
Starting KMail from console gives the following output:
error QNetworkReply::ConnectionRefusedError error string : "Connection refused"
[14645:14701:1028/110449.990783:ERROR:address_tracker_linux.cc(201)] Could not bind NETLINK socket: Address already in use (98)
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
org.kde.pim.webengineviewer: Invalid Data.
org.kde.pim.webengineviewer: WebEngine render process crashed
org.kde.pim.webengineviewer: WebEngine render process crashed
org.kde.pim.webengineviewer: WebEngine render process crashed
After some research I found that webengineviewer is also crashing when launching Akregator. Other QT apps might be having the same problem as well.
As a workaround, setting the environment variable QTWEBENGINE_DISABLE_SANDBOX to 1 seems to solve the issue.
I'm guessing the CL kernel isn't meeting the requirements for sandboxing in webengine as these would have some interesting security implications. In any case, any clarification on this matter is welcome.
I'll check the kernel requirements but... it is also possible that our glibc supports newer systemcalls than the seccomp rules of the legacy webengineview supports
seccomp is a huge trap that way unfortunately
On Wed, Nov 1, 2023 at 5:21 AM Juan Sosa @.***> wrote:
After some research I found that webengineviewer is also crashing when launching Akregator. Other QT apps might be having the same problem as well.
As a workaround, setting the environment variable QTWEBENGINE_DISABLE_SANDBOX to 1 seems to solve the issue.
I'm guessing the CL kernel isn't meeting the requirements for sandboxing in webengine https://doc.qt.io/Qt-5/qtwebengine-platform-notes.html#sandboxing-support as these would have some interesting security implications. In any case, any clarification on this matter is welcome.
— Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/2986#issuecomment-1788863141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ54FMJC6IQMIEXLAMNUN3YCI5FDAVCNFSM6AAAAAA6T7SXS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBYHA3DGMJUGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yeah, I hadn't considered glibc, makes sense. Thanks for your insight.