[tbb-bugs] #24177 [Applications/Tor Browser]: screenshot command in Web Developer toolbar is broken in Tor Browser

[Tor Bug Tracker & Wiki]

#24177: screenshot command in Web Developer toolbar is broken in Tor Browser
--------------------------------------+--------------------------
 Reporter:  cypherpunks               |          Owner:  tbb-team
     Type:  defect                    |         Status:  reopened
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-usability             |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by gk):

 Replying to [comment:10 pospeselr]:
 > Replying to [comment:9 gk]:
 > > That's due to #22692. I get the following in my terminal:
 > > {{{
 > > Message: Unix error 13 during operation stat on file image_name
 > > }}}
 > > Setting `security.sandbox.content.level` to anything less than `2` it
 "works". I wonder if #23970 would fix this issue as well.
 >
 > It does not (which isn't terribly surprising).  The patches in #23970
 are specifically about serializing over the relevant font information from
 the sandboxed Web Content process to foreground firefox process so that
 the print.print_via_parent option works correctly.  Prior to the changes
 there, the print_via_parent option 'worked' but no fonts would be in the
 final rendered pdf/ps file.
 >
 > The issue here is almost certainly a file permissions issue since if you
 explicitly set a path the sandbox process has access to with the
 screenshot command (ie {{{ screenshot /tmp/screenshot.png }}} the
 operation succeeds.  The generated screenshot file and path will need to
 be broker'd over to the foreground which has access to the user's file
 system.
 >
 > The reason why some pages (empty tab, about:support, etc) can be
 screenshot (or successfully print-to-file'd prior to the #23970 fix) is
 (presumably) because they are hosted in the firefox process, rather than
 the sandboxed Web Content process, which seems kind of off.  For instance,
 if the strings in the about:support page are not properly sanitized, I
 could imagine sandbox-escape where a malevolent extension exercising some
 exploit through a malicious string in the Name, Version or ID strings.

 Makes sense, thanks. So, the question boils down to why just specifying a
 filename without an absolute path is working in vanilla Firefox but not
 Tor Browser then I guess.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24177#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online