Closed
Bug 817007
Opened 12 years ago
Closed 9 years ago
Consider removing "<file>" hack from the permission manager
Categories
(Core :: General, defect)
Core
General
Tracking
()
RESOLVED
FIXED
mozilla42
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: mounir, Assigned: nika)
References
Details
Attachments
(2 files)
2.98 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
1.89 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
Currently, if there is an entry with "<file>" as a host in the permission manager, the expected behaviour is that this will apply for all local files. With bug 815640, it will only apply to a file that doesn't already have an explicit permission listed. Using <file> is a security issue (a user can trust certain files but not others) and there is nearly no downside in having this feature removed in favour of per-file permissions except for someone who would test a website locally with heavy permissions usage.
Comment 1•11 years ago
|
||
Fix the user interface first, because currently <file> is the only exception type that can be created from the cookie exceptions dialog. As an example, entering "file:///tmp/test.html" in the dialog will produce an exception for host "tmp". Entering "<file>" in the same dialog does at least create a usable exception even if it would be preferable to have separate ones for each path. A full file URL exception can be set from the dialog that appears to ask about each cookie (assuming that custom privacy setting is configured), although the about:permissions page will mis-report the permissions for that file and will not report any cookies set by it. I have raised bug 921280 for the about:permissions problem. Even then it might be wise to leave the hack in place so that existing permissions are not wiped out, or worse yet a repeat of the bug 814554 breakage. There is no meaningful way to migrate an all-encompassing "<file>" exception to the new regime, but perhaps the dialog could be prevented from creating any more permissions of that type. Or a stronger form of warning?
Comment 2•9 years ago
|
||
Let's drop support for this now that bug 1165263 is being fixed. Michael has already fixed the UI issue in comment 1.
Assignee: nobody → michael
Blocks: 1165263
Assignee | ||
Comment 3•9 years ago
|
||
Attachment #8623318 -
Flags: review?(ehsan)
Assignee | ||
Comment 4•9 years ago
|
||
Attachment #8623319 -
Flags: review?(ehsan)
Assignee | ||
Comment 5•9 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=20e7bc07e645
Comment 6•9 years ago
|
||
Comment on attachment 8623318 [details] [diff] [review] Part 1: Remove <file> hack from the permission manager Review of attachment 8623318 [details] [diff] [review]: ----------------------------------------------------------------- (Please hold off landing this patch, all of your permission manager changes should land together, I think.)
Attachment #8623318 -
Flags: review?(ehsan) → review+
Updated•9 years ago
|
Attachment #8623319 -
Flags: review?(ehsan) → review+
Comment 7•9 years ago
|
||
(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #6) > (Please hold off landing this patch, all of your permission manager changes > should land together, I think.) Or more precisely, in the next cycle. :-)
https://hg.mozilla.org/integration/mozilla-inbound/rev/bfa100253349 https://hg.mozilla.org/integration/mozilla-inbound/rev/c6bda3a0afd6
This (and everything else from ehsan's push) backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/de3fb216f066 for mass android reftest bustage: https://treeherder.mozilla.org/logviewer.html#?job_id=11676048&repo=mozilla-inbound
Flags: needinfo?(michael)
Comment 10•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/772af1e461f9 https://hg.mozilla.org/integration/mozilla-inbound/rev/23ed8a21698e
Comment 12•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/772af1e461f9 https://hg.mozilla.org/mozilla-central/rev/23ed8a21698e
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•