1061136 - local (file://) links don't work if capability.policy.localfilelinks.sites without protocol and if only domain/only protocol

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[Alice0775 White]

Attachment: test html

Comment 1

[Alice0775 White]

Attachment: user.js

Comment 2

[Alice0775 White]

Attachment: user.js without protocol

Comment 3

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #995943 +++

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140831030206

Firefox 28 works as expected.
This bug exist since Firefox 31.


Steps to reproduce:

1. Create a new profile and copy "user.js" attachment 8482203 [details] to the profile folder
2. Start browser
3. Open attachment 8482197 [details]
4. Click a link "file:///c:/windows/win.ini"
   --- nothing happens in Nightly34.  It works as expected in Filrefox28.

It works if a protocol is specified(see attachment 8482198 [details]). 


Actual Results:
No thing happen

Expected results:
File c:/windows/win.ini contents should display.

Comment 4

[Alice0775 White]

Attachment: user.js only domain

This also works in Firefox28.
However, this dose not work in Firefox31 and later.

Comment 5

[Alice0775 White]

Attachment: user.js only protocol

This also works in Firefox28.
However, this dose not work in Firefox31 and later.

Comment 6

[Bobby Holley (:bholley)]

Protocol-only is WONTFIX for the reasons outlined in bug 1028321 comment 2.

The "without protocol" case does seem like a potential pain-point. I think we can fix 95% of that pain by just assuming http:// there. I'll attach a patch.

Comment 7

[Bobby Holley (:bholley)]

Attachment: Assume http:// for schemeless URIs in CAPS prefs. v1

Comment 8

[Bobby Holley (:bholley)]

[Tracking Requested - why for this release]:

We'll want this on esr31, since this is currently the last overlap cycle of esr31, and this has the potential to reduce pain when large organizations make the switch in 6 weeks.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8483014 [details] [diff] [review]
Assume http:// for schemeless URIs in CAPS prefs. v1

r=me

Comment 11

[Alice0775 White]

So, after the above patch landing, 
Open local file from http://host.domain and https://host_ssl.domain_ssl (ssl site),


Not supported format:
https:  http:  --- was rejected by bug 1061128 comment#2?
host_ssl.domain_ssl [1]
domain  domain_ssl  [2]


Supported format:
http://host.domain  https://host_ssl.domain_ssl --- was added by bug 1061128
host.domain   --- will be added by this bug 1061136


What about [1] and [2]?

Comment 12

[Bobby Holley (:bholley)]

Hm, I guess it makes sense to add _both_ http:// and https:// to the whitelist in the case of schemeless domains. I'll attach an updated patch.

Comment 13

[Bobby Holley (:bholley)]

Attachment: Assume both http:// and https:// for schemeless URIs in CAPS prefs. v2

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8485320 [details] [diff] [review]
Assume both http:// and https:// for schemeless URIs in CAPS prefs. v2

Yeah, makes sense.

Comment 15

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2092f7bd26d2

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2092f7bd26d2

Comment 17

[Bobby Holley (:bholley)]

Attachment: Followup bugfix. v1

This was a stupid error I introduced in this bug, whereby schemeless hosts
cause subsequent sites to be ignored. I discovered it in bug 1053725, and
incidentally the test changes made in that bug serve as test coverage for this
patch.

I know that serial landings in a single bug aren't all that kosher, but I think
it's probably fine in this case, and simplifies things a bit when we uplift all
this to esr.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8486098 [details] [diff] [review]
Followup bugfix. v1

Ouch.  I should have caught that!

r=me

Comment 19

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6db078d61361

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6db078d61361

Comment 21

[Bobby Holley (:bholley)]

Comment on attachment 8485320 [details] [diff] [review]
Assume both http:// and https:// for schemeless URIs in CAPS prefs. v2

This request applies to both patches in this bug. It makes the enterprise pref configurations for local file:// links more backwards compatible.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: When large organizations switch over to esr31, they're more likely to find that their old pref files don't work, wasting time both in diagnosis and in deploying a fix.
Fix Landed on Version: 35
Risk to taking this patch (and alternatives if risky): Very low risk 
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 22

[Bobby Holley (:bholley)]

Comment on attachment 8485320 [details] [diff] [review]
Assume both http:// and https:// for schemeless URIs in CAPS prefs. v2

See bug 1053725 comment 11. Don't forget the followup bugfix.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1cf9afc1f606
https://hg.mozilla.org/releases/mozilla-beta/rev/e608db37bafb
https://hg.mozilla.org/releases/mozilla-esr31/rev/1cfc6d945632

I folded the follow-up fix into the original patch.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Either this or bug 1053725 appears to have broken Marionette :(
https://tbpl.mozilla.org/php/getParsedLog.php?id=48107396&tree=Mozilla-Esr31

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Nevermind that, this is mozharness bustage.

Comment 26

[Bobby Holley (:bholley)]

Attachment: Get sIOService before invoking ReadPrefs. v1

Comment 27

[Bobby Holley (:bholley)]

Comment on attachment 8489983 [details] [diff] [review]
Get sIOService before invoking ReadPrefs. v1

Sorry, wrong bug.