1175881 - about:sync-log can't read files on OS X with e10s on and content process sandbox enabled

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Catalin Varga [QA][:VarCat]]

Environment:

FF 41
OS: Mac Os X 10.9.5

STR:

1. From about:config set services.sync.log.appender.file.logOnSuccess;true
2. Perform a sync.
3. Open one of the sync logs from about:sync-log

Issue:
The sync log is not displayed.

Note:
This bug is not reproducible with e10s disabled.
This bug is not reproducible on Windows.

Comment 1

[Tracy Walker [:tracy]]

Catalin, did you restart the browser after step 2?  (iirc, it is required to make the config change stick)

Comment 2

[Catalin Varga [QA][:VarCat]]

I've tried again using the latest FF 42 Nightly and I've restarted the browser after step 2, the bug is still reproducible.

Comment 3

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

Can you try disabling the sandbox by setting security.sandbox.content.level to 0

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I'll wait to respond until after Catalin answers comment #3.

Comment 5

[Catalin Varga [QA][:VarCat]]

The bug is not reproducible when security.sandbox.content.level is set to 0 .

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I have some more questions for you, Catalin:

Does the bug happen with a clean profile (save for the change you made in your step 1)?

Is the bug a recent regression?  For example, does it also happen with FF 39, FF 40 beta and current Developer Edition nightlies (with clean profiles)?

What directory is displayed in about:sync-log?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Is the bug a recent regression?  For example, does it also happen
> with FF 39, FF 40 beta and current Developer Edition nightlies (with
> clean profiles)?

Oops, sorry.  I forgot this bug only happens in e10s mode, with the
content sandbox on.  Do test in a current Developer Edition nightly,
though, with e10s on.

Comment 8

[Tracy Walker [:tracy]]

(In reply to Steven Michaud [:smichaud] from comment #6)

> What directory is displayed in about:sync-log?

sync logs are in the profile under: /Users/<user>/Library/Application Support/Firefox/Profiles/<salted profile>/weave/

Is that inaccessible when running sandboxed?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> Is that inaccessible when running sandboxed?

I don't believe so.  But the relevant sandbox rules are very complex, and it's possible I'm reading them wrong.

In any case, I want to get as much information as I can before I start digging into this.

Comment 10

[Catalin Varga [QA][:VarCat]]

The bug is not reproducible on the latest FF 41 DevEdition with e10s enabled, the bug is reproducible using 
a new profile and the latest FF 42 Nightly build id:20150716030208 .

The directory displayed under about:sync-log is:

///Users/svuser/Library/Application Support/Firefox/Profiles/7ybfeu28.73/weave/logs

Comment 11

[Steven Michaud [:smichaud] (Retired)]

I can reproduce this bug with yesterday's m-c nightly.  (For some reason there isn't any Mac m-c nightly for today.)

Oddly, the browser has no problem *writing* sync logs -- only reading them.  I suspect they're written by the main/chrome process, but read by the content process.  That isn't ideal -- all file access should (ultimately) be brokered through the chrome process.

But in the meantime we do need to fix our content process sandbox rules.

I wasn't able to reproduce this bug in yesterday's Developer Edition.  The reason, it seems, is that the content process sandbox is either missing or off in the Developer Edition.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

This is a minimal patch -- it fixes just this bug as reported.

I figure anything more ambitious should wait until we've proxied as much file access as we can through the main/chrome process.

Comment 13

[André Reinald]

Comment on attachment 8639475 [details] [diff] [review]
Fix

Review of attachment 8639475 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, that's the only way we can work around such issues for now.
Looks fine to me.

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/567e17d291f9

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/567e17d291f9

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8639475 [details] [diff] [review]
Fix

Approval Request Comment
[Feature/regressing bug #]: bug 1083344
[User impact if declined]: Pretty bad UI bug
[Describe test coverage new/current, TreeHerder]: Baked for a week on m-c
[Risks and why]: Very low -- fix is very simple and precisely focused.
[String/UUID change made/needed]: None

Comment 17

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8639475 [details] [diff] [review]
Fix

Seems like a simple change, let's uplift to Aurora.

Comment 18

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Catalin, could you please verify this fix on the latest Nightly build? Thanks.

Comment 19

[Catalin Varga [QA][:VarCat]]

Verified as fixed:

FF 42
Build id: 20150809030213
OS: Mac Os X 10.10.4

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/af45324d7bb9