Closed Bug 1043470 Opened 10 years ago Closed 9 years ago

Temp files reported as used during mochitests by the Windows warn only sandbox

Categories

(Core :: Security: Process Sandboxing, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bobowen, Unassigned)

References

Details

Attachments

(5 files)

Just a placeholder bug to store these partial log files from the mochitests running with the warn only sandbox.

These files include all of the messages reported by the filesystem interception code. Not everything there is for temp files and there are a lot of repeats for the same file.
I've cut most of the stuff out of the logs, but I've included the TEST-START before each set of file access starts.

I've also cut out the stack traces, as these don't seem to be reliable on the try servers for some reason.

In case you want the full logs, they were taken from the Windows 7 Debug tests of this try run:
https://tbpl.mozilla.org/?tree=Try&rev=35e363f010cd

Note: if we provide a low integrity temp directory (see bug 1018988), these will work with our current sandbox integrity level, although it would prevent us from lowering it further.
The ones where the filename is 8 random characters followed by ".tmp" are probably from nsDownloader::OnStartRequest, which is covered by bug 1034143.  Changing that method to use a more distinctive name template and rerunning try would confirm it.

The rest of the regular files look like specific mochitests using SpecialPowers to access filesystem operations directly; maybe some or all of them could be converted to chrome tests?  Specifically, I see:

* Tests under `content/html` using SpecialPowers.MockFilePicker or otherwise doing tests specific to the file upload widget. 

* Tests under `embedding` covering nsWebBrowserPersist.
(In reply to Jed Davis [:jld] from comment #6)
> The ones where the filename is 8 random characters followed by ".tmp" are
> probably from nsDownloader::OnStartRequest, which is covered by bug 1034143.
> Changing that method to use a more distinctive name template and rerunning
> try would confirm it.

Confirmed this, thanks:
https://tbpl.mozilla.org/?tree=Try&rev=9b2986c79c6b

grep wibble *|wc
   66     825   13675

grep "[a-z0-9]\{8\}\.tmp" *|wc
   66     825   13675
Depends on: 1034143
Move process sandboxing bugs to the new Bugzilla component.

(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)
Component: Security → Security: Process Sandboxing
Bug 1034143 is closed now, and the other tests mentioned in comment #6 are probably the same ones I've already fixed.  It might be worth doing another run and seeing what the current status is.
(In reply to Jed Davis [:jld] from comment #9)
> Bug 1034143 is closed now, and the other tests mentioned in comment #6 are
> probably the same ones I've already fixed.  It might be worth doing another
> run and seeing what the current status is.

Thanks Jed.
The logging has changed a bit since this bug, so I'll have to think how I reproduce this.
Flags: needinfo?(bobowen.code)
(In reply to Jed Davis [:jld] from comment #9)
> Bug 1034143 is closed now, and the other tests mentioned in comment #6 are
> probably the same ones I've already fixed.  It might be worth doing another
> run and seeing what the current status is.

Yeah, I don't see any of these messages in a recent run, so I think they've all been covered, thanks.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bobowen.code)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: