Details
Description
I'm experiencing problems using qtwebengine in a Qt application that runs within a low integrity level (IL) sandboxed process with mostly read-only access to the filesystem. The problem also seem to affect AppContainer-isolated processes.
Steps to reproduce:
- Build the webenginewidgets\minimal project in debug mode.
- From a administrative command-prompt, run icacls minimal-widgets.exe /setintegritylevel Low to make the executable run in a low IL process.
- Start the minimal-widgets.exe debug build with a debugger attached.
- Observe a startup crash with the following call stack:
1 logging::LogMessage::~LogMessage 2 logging::LogMessage::`scalar deleting destructor' 3 logging::CheckError::~CheckError 4 logging::CheckError::DCheck 5 content::GetPseudonymizationSalt 6 content::ChildProcessHostImpl::OnChannelConnected 7 IPC::ChannelMojo::OnPeerPidReceived 8 IPC::internal::MessagePipeReader::SetPeerPid 9 IPC::mojom::ChannelStubDispatch::Accept 10 IPC::mojom::ChannelStub<mojo::RawPtrImplRefTraits<IPC::mojom::Channel>>::Accept 11 mojo::InterfaceEndpointClient::HandleValidatedMessage 12 mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept 13 mojo::MessageDispatcher::Accept 14 mojo::InterfaceEndpointClient::HandleIncomingMessage 15 IPC::`anonymous namespace'::ChannelAssociatedGroupController::Accept 16 mojo::MessageDispatcher::Accept 17 mojo::Connector::DispatchMessageW 18 mojo::Connector::ReadAllAvailableMessages ...... 42 QtWebEngineCore::MessagePumpForUIQt::handleScheduledWork 43 <lambda_84a6b7d6105a320ed8553761646d4ffd>::operator() 44 std::invoke<<lambda_84a6b7d6105a320ed8553761646d4ffd> &> 45 std::_Invoker_ret<void,1>::_Call<<lambda_84a6b7d6105a320ed8553761646d4ffd> &> 46 std::_Func_impl_no_alloc<<lambda_84a6b7d6105a320ed8553761646d4ffd>,void>::_Do_call 47 std::_Func_class<void>::operator() 48 QWebEngineMessagePumpScheduler::timerEvent 49 QObject::event 50 QApplicationPrivate::notify_helper 51 QApplication::notify 52 QCoreApplication::notifyInternal2 53 QCoreApplication::sendEvent 54 QCoreApplicationPrivate::sendPostedEvents 55 QEventDispatcherWin32::sendPostedEvents 56 QWindowsGuiEventDispatcher::sendPostedEvents 57 QEventDispatcherWin32::processEvents 58 QWindowsGuiEventDispatcher::processEvents 59 QEventLoop::processEvents 60 QEventLoop::exec 61 QCoreApplication::exec 62 QGuiApplication::exec 63 QApplication::exec 64 main 65 WinMain
It seems like the root-cause is a failing DCHECK(!sandbox::policy::Sandbox::IsProcessSandboxed()) check in the content::GetPseudonymizationSalt function on line 5 in the call stack.
Suggested fix
Delete the failing DCHECK(!sandbox::policy::Sandbox::IsProcessSandboxed()) check in the content::GetPseudonymizationSalt function in chromium. The IsProcessSandboxed heuristic seem flawed to me, since the browser/parent process might also be sandboxed when embedding the chromium engine in an application - as in my case. This check seem to have been introduced in https://github.com/chromium/chromium/commit/2b8b8623c710f150091db6fc7904f28976fcc336 . Upstream code link: https://github.com/chromium/chromium/blob/main/content/common/pseudonymization_salt.cc
Attachments
For Gerrit Dashboard: QTBUG-108904 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
445692,2 | Fix browser DCHECK | 106-based | qt/qtwebengine-chromium | Status: MERGED | +2 | 0 |
445916,3 | FIXUP: Fix browser DCHECK | 106-based | qt/qtwebengine-chromium | Status: MERGED | +2 | 0 |