--enable-sandbox-logging doesn't work |
|||||
Issue descriptionChrome Version: 69.0.3497.12 OS: MacOS The --enable-sandbox-logging switch (https://cs.chromium.org/chromium/src/services/service_manager/sandbox/switches.cc?rcl=2843aa63513d819e56c1ba4d52fd54207e511a31&l=100) mentioned in https://www.chromium.org/developers/how-tos/debugging-on-os-x#TOC-Tips-on-Debugging-the-Renderer-Sandbox doesn't seem to have any effect. It would be really useful when debugging issues with the V2 sandbox.
,
Aug 6
Hmm, maybe it's an issue in seatbelt itself? This $ sandbox-exec -p '(version 1) (allow default) (debug deny) (deny file-write* (regex "foo"))' touch foo adds no entries to system.log.
,
Aug 6
Indeed we sent Apple a radar, we think seatbelt logging is broken in the upstream OS.
,
Aug 6
,
Aug 6
Right. Thanks for confirming. In the meantime, do you have any hints as to how to go about figuring out what to allow in order to migrate from AudioToolbox warm-up to explicit sandbox directives?
,
Aug 13
No, we unfortunately there is not a great way to debug at the moment. You can use dtruss to track failed syscalls, but that won't handle things like Mach lookups. I encourage you to file an additional radar to get more attention on the issue. Ours is rdar://41644488.
,
Aug 14
Good idea. Filed rdar://43271636. I've noticed the problem in macOS 10.13, but it still works in 10.10 (and perhaps some other versions too). Unfortunately, the right sandbox directives also sometimes depend on the OS version.
,
Aug 14
Yes, I tracked down the regression to starting in 10.13.4, and it also affects the 10.14 betas.
,
Oct 8
Fixed in 10.14.1 18B57c. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by wdzierza...@opera.com
, Aug 6