Open Bug 1395321 Opened 3 years ago Updated 3 years ago
64-bit Flash on Windows - Print to file silently fails to write file
Bug 1388903 (broken print dialog) exposed this issue. The print-to-file mechanism does use GetSaveFileNameW, which we broker since the sandboxed process has severely limited file access. For some as yet unknown reason, the file write still fails.
Priority: -- → P3
Whiteboard: sb? → sb+
What we know so far: The sandbox is blocking the operations of WINSPOOL!StatrtDocPrinterInternal (called by WINSPOOL!StartDlgW) when printing to file. GDI still seems to draw the document, even though it's not saved (it fails before drawing). I'm not sure what aspect of the sandbox is responsible for blocking this but we aren't going to weaken the sandbox anyway. The particular this is the part of StatrtDocPrinterInternal where behavior diverges: WINSPOOL!StartDocPrinterInternal+0x572: 00007ffe`baf10486 488d4504 lea rax,[rbp+4] 00007ffe`baf1048a 4889442428 mov qword ptr [rsp+28h],rax 00007ffe`baf1048f 488d8580000000 lea rax,[rbp+80h] 00007ffe`baf10496 4889442420 mov qword ptr [rsp+20h],rax 00007ffe`baf1049b 4d8b4d08 mov r9,qword ptr [r13+8] 00007ffe`baf1049f 4533c0 xor r8d,r8d 00007ffe`baf104a2 418d5011 lea edx,[r8+11h] 00007ffe`baf104a6 488d0d4b7e0200 lea rcx,[WINSPOOL!winspool_ProxyInfo (00007ffe`baf382f8)] 00007ffe`baf104ad ff1545dc0400 call qword ptr [WINSPOOL!_imp_NdrClientCall3 (00007ffe`baf5e0f8)] 00007ffe`baf104b3 48894540 mov qword ptr [rbp+40h],rax 00007ffe`baf104b7 894500 mov dword ptr [rbp],eax 00007ffe`baf104ba 85c0 test eax,eax 00007ffe`baf104bc 740f je WINSPOOL!StartDocPrinterInternal+0x5b9 (00007ffe`baf104cd) Branch The call to WINSPOOL!_imp_NdrClientCall3 is an RPC call. It returns an error in eax. It could mean anything but I note that eax is 0x5: ERROR_ACCESS_DENIED (how helpful). Investigating the RPC call (which likely won't bear fruit) is very involved. We need to dig in for this.
More info: It turns out the low integrity level is the reason for the sandbox failure. Saving does work at sandbox level 1 . None of the "easy" fixes to sandbox failures worked -- I tried permitting all registry and Local/Roaming user directory access with no luck. So... hard. ---  Note that you can't set NPAPI sandbox level 1 without changing code. It is hardwired to be at least 2 unless MOZ_DISABLE_NPAPI_SANDBOX is defined, in which case it is obviously irrelevant. See http://searchfox.org/mozilla-central/rev/44c693914255638d74bcf1ec3b0bcd448dfab2fd/dom/plugins/base/nsPluginTags.cpp#415
You need to log in before you can comment on or make changes to this bug.