Open Bug 1395321 Opened 3 years ago Updated 3 years ago

64-bit Flash on Windows - Print to file silently fails to write file


(Core :: Plug-ins, enhancement, P3)





(Reporter: handyman, Unassigned)



(Keywords: 64bit, flashplayer, Whiteboard: sb+)

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.
Depends on: 1388903
Flags: needinfo?(davidp99)
Priority: -- → P3
Whiteboard: sb? → sb+
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:

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.
Flags: needinfo?(davidp99)
More info:

It turns out the low integrity level is the reason for the sandbox failure.  Saving does work at sandbox level 1 [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.


[1] 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
Whiteboard: sb? → sb+
You need to log in before you can comment on or make changes to this bug.