1146969 - about:sync-log does not open files with the sandbox enabled

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect)

Description

[Andrew McCreight [:mccr8]]

If I go to about:sync-log in e10s mode, it lists all of the files, but I just get a blank page if I click on one of the files.  It works fine in a non-e10s window.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

suggestion from triage is to make this page run in the chrome process

Comment 2

[Dave Townsend [:mossop]]

So getURIFlags for this about module returns 0, which should mean it always loads in the parent. I suspect because it returns a file: channel we're probably using the file: URI to decide where to load. Maybe set the channel's originalURI to the about: URI before returning from newChannel to fix this?

http://mxr.mozilla.org/mozilla-central/source/services/sync/Weave.js#176

Comment 4

[Mark Hammond [:markh] [:mhammond]]

The problem doesn't appear to be related to about:sync-log, but simply to the file URLs in the directory listing - eg, copy/pasting one of the file:// URLs into a new tab exhibits the same behaviour.  If you whitelist file:// URLs in e10sutils.jsm to always load in the parent things also work fine.

Also, for me, file:///Users/skip works, but stops working as soon as I enter "Library".  Mossop's current guess given this information is that the sandbox is restricting it.

Comment 5

[Richard Newman [:rnewman]]

Marking as blocking Bug 1152140, in the hope that it fixes it, but not dupe -- I hit this without e10s.

Comment 6

[Richard Newman [:rnewman]]

Note that I'm loading my entire browser session without e10s. Not sure if that's different to Comment 0's experiment with a non-e10s *window*.

Comment 7

[Justin Dolske [:Dolske]]

FWIW, dtruss shows that clicking Library from file://Users/dolske is being opened in the child, and is bring rejected in the syscall. So would sound like a sandbox issue... (WFM with no E10S)

# dtruss -p 99806 -s
...
open_nocancel("/Users/dolske/Library\0", 0x1100004, 0x1037C0F04)>--->--- = -1 Err#1

              libsystem_kernel.dylib`__open_nocancel+0xa
              XUL`nsDirEnumeratorUnix::Init(nsLocalFile*, bool)+0x7d
              XUL`nsLocalFile::GetDirectoryEntries(nsISimpleEnumerator**)+0x8b
              XUL`nsDirectoryIndexStream::Init(nsIFile*)+0x10a
              ...

Comment 9

[Dave Townsend [:mossop]]

I think smichaud knows about the sandbox and can enlighten us here

Comment 10

[Steven Michaud [:smichaud] (Retired)]

As Dolske noticed, we're handling file:// URLs in the child process.  But should be handling them in the chrome process.  Bug 922481 has been opened on this issue.

I'd really like to wait until this bug is fixed by doing that.

If we can't wait, we *could* add more exceptions to the set of content process sandbox rules at bug 1083344.  But we've already rejected a "read anything anywhere" rule in the default (level 1) ruleset.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Hey Michal, what does the timeline for bug 922481 look like? We'd like to fix this bug pretty soon, but if the other bug is making progress, then we could probably push this out a little.

Comment 13

[Michal Novotny [:michal]]

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #12)
> Hey Michal, what does the timeline for bug 922481 look like? We'd like to
> fix this bug pretty soon, but if the other bug is making progress, then we
> could probably push this out a little.

I won't get to it at least next 2-3 weeks.

Comment 14

[Edwin Wong [:edwong]]

moving to e10s - not a sync issue

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

This works for me now.