[Development] Getting QtWebEngineProcess.app to run in sandbox after being signed

Alexandru Croitor alexandru.croitor at qt.io
Mon May 8 10:43:01 CEST 2017


Well, to be fair, it seems you haven't heeded my advice, and are going with the approach of sandboxing the whole application, instead of leaving that to be done by Chromium.

Regarding the issues you are seeing now, it is because of the "com.apple.security.application-groups" entitlement key. That value (team id + "." + random domain-like suffix string) has to be used by Chromium code, so that access is granted to the cross-process resources. By default Chromium uses "org.chromium.Chromium" prefix as the application group key, which results in the permission denied issues.

You can modify the "BaseBundleID" method in "/qt_source/qtwebengine/src/3rdparty/chromium/base/mac/foundation_util.mm:241" to hardcode the bundle id to your "team_id + suffix" entitlement key. That made it work for me.

Regards, Alex.

On 06 May 2017, at 14:46, Adalid Claure <aclaure at gmail.com<mailto:aclaure at gmail.com>> wrote:

FWIW, I tried these changes but like you said I ran into another error (though, I'm pretty sure it's one I've seen before).

5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5958) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957
5/6/17 08:35:40.000 kernel[0]: Sandbox: QtWebEngineProce(5959) deny(1) mach-lookup org.chromium.Chromium.rohitfork.5957
5/6/17 08:35:40.070 QtWebEngineProcess[5958]: [0506/083540:ERROR:mach_port_broker.mm<http://mach_port_broker.mm/>(43)] bootstrap_look_up: Permission denied (1100)
5/6/17 08:35:40.070 QtWebEngineProcess[5959]: [0506/083540:ERROR:mach_port_broker.mm<http://mach_port_broker.mm/>(43)] bootstrap_look_up: Permission denied (1100)

Does this look like the other issues you were referring to?

There is progress in the sense that the QtWebEngine widget is now white, instead of invisible (since it wasn't loading, I presume) like before. Of course, nothing renders inside it though.

On Thu, May 4, 2017 at 9:32 AM, Alexandru Croitor <alexandru.croitor at qt.io<mailto:alexandru.croitor at qt.io>> wrote:
It's in the function SandboxCompiler::CompileAndApplyProfile in
the whole if branch.

But please do note my warning, even if it appears to work, it does not mean you will not have issues. Chromium has its own special sandbox profile (set of rules) that it applies to the subprocess, and it never applies it to the main process. So by simply enabling default sandboxing for both, you invite untested territories.

On 04 May 2017, at 15:26, Adalid Claure <aclaure at gmail.com<mailto:aclaure at gmail.com>> wrote:

I am the one who logged the bug.

Can you point me to the line of code that you commented out where you were able to get it to work?

On Thu, May 4, 2017 at 9:15 AM, Alexandru Croitor <alexandru.croitor at qt.io<mailto:alexandru.croitor at qt.io>> wrote:

I'm actually looking into this at the moment, as per the created issue here QTBUG-60443

I haven't completely finished my investigation, which I will post to the bug report.

But the gist of it is:
- the WebEngine / Chromium sub process calls manually sandbox_init, which is the macOS private API for enabling the sandbox. That interferes
with the sandbox which you enable via codesign entitlements, which gives the "sandbox reinit denied' issue, and crashed process.

- if the above call is commented out, then you need to make sure that the Qt Application is signed with sandbox setup entitlements, and the WebEngineProcess is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to  work.

- Both of those entitlements have to specify a valid Team ID + prefix in the entitlment com.apple.security.application-groups

- Google Chrome itself does not enable sandboxing via codesign entitlements, but only enables it for subprocess via sandbox_init, leaving the main process without a sandbox.

Thus my preliminary suggestion is not to enable codesign sandboxing for QtWebengine applications.

I'm open to discussion on this though.

Note that the private API use inside WebEngine, which is removed via appstore_compliant configure switch, is a separate issue from sandboxing.

Regards, Alex.

On 04 May 2017, at 14:45, Morten Sørvig <Morten.Sorvig at qt.io<mailto:Morten.Sorvig at qt.io>> wrote:


Not sure if I can be of much help, but:

- This thread discusses and solves a similar problem: https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application

- If this could be reduced to a simple sandboxed-app-with-helper-process test case (no QtWebEngine usage), that that’s something I could look at, and something we could eventually add an autotest for.


On 28 Apr 2017, at 18:49, Adalid Claure <aclaure at gmail.com<mailto:aclaure at gmail.com>> wrote:

I have a desktop app that I have been trying to get onto the Mac App store but I have been having problems getting it to run in sandbox mode. For context I am (preferably) using Qt 5.8 running on macOS 10.11.6.

The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the bundle. As a result, my QtWebEngine component doesn't load. I am using this QtWebEngine component as part of my app's UI.

When the app starts I see the following errors in Console:

kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763
kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup org.chromium.Chromium.rohitfork.20763
QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm<http://mach_broker_mac.mm/>(52)] bootstrap_look_up: Permission denied (1100)
QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm<http://mach_broker_mac.mm/>(52)] bootstrap_look_up: Permission denied (1100)
kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit

My build process is pretty straight forward:

1. Run macdeployqt on the app, using the -appstore-compliant.
2. Sign all of the Qt Frameworks and PlugIns individually with my app's entitlement file.
3. Sign QtWebEngineProcess.app with the following entitlements file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

4. Call codesign on the overall MyProgram.app bundle with the entitlements file from Step 2.

I have tried numerous things all in combination with one another, including:

a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility)
b. use macdeployqt's -codesign, even though the binarys have to be signed a second time after this in order to apply the entitlements
c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID.
d. tried linking with Qt 5.7
e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple because:

Your app uses or references the following non-public API(s):

framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit'
: NSAccessibilityUnregisterUniqueIdForUIElement
: _NSAppendToKillRing
: _NSDrawCarbonThemeBezel
: _NSDrawCarbonThemeListBox
: _NSInitializeKillRing
: _NSNewKillRingSequence
: _NSPrependToKillRing
: _NSSetKillRingToYankedState
: _NSYankFromKillRing

framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
: CGSSetDenyWindowServerConnections
: CGSShutdownServerConnections
: CTFontCopyDefaultCascadeList

The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change.

I have chronicled a lot of this in this thread here (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists.

Does anyone have any suggestions? Does anyone know of any apps on the Mac App Store that use QtWebEngine?

Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>

Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170508/60532251/attachment.html>

More information about the Development mailing list