[RFE] Allow graded access to file:// links within mailnews



17 years ago
11 years ago


(Reporter: iann_bugzilla, Unassigned)


(Depends on 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
Using buildid 2002040210 on Windows XP
Reproducible: Always

Steps to Reproduce
1. Get someone using N.4x to email you a link to a file on a shared network drive.
2. Try clicking on link

Actual Result.
Clicking on link does nothing

Expected Result:
Clicking on link opens file from shared network drive.

Comment 1

17 years ago
This works fine in NS4.x so I'll mark as 4xp
Keywords: 4xp
Invalid.  Remote content cannot link to local content for security reasons.  
Mail is remote content.

See bug 84128 for discussion on the issue as well as the pref you can set to 
disable this security check (in bug 84128, comment 20)
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 3

17 years ago
Bug 84128 is to do with browser file:// links and whether it pops up a window
and what sort of window it should pop up. This is a change in behaviour from
NS4.x and users, used to NS4.x, will be confused by the change and lack of
explanation. Corporates tend to encourage use of links to files on shared
network drives rather than sending huge attachments round and eating up disk space.

A file:// link in an email doesn't pop up any sort of window error or dialog!

The user_pref("security.checkloaduri", false) mentioned seems to be to black and
white, there should be some sort of grading. I think the Mozilla should be able
to determine whether it is an internal e-mail (or a list of safe domains which
it auto-fills with your domain when you run mail account wizard) or an external
e-mail (or those not in your list of safe domains) and have preferences to let
you configure what Mozilla does with file links in each circumstance.

Reopening and tweaking summary.
Resolution: INVALID → ---
Summary: file:// links sent from NS4.x do not open in Mozilla → file:// links sent from NS4.x do not open in Mozilla or pop up an explaination

Comment 4

17 years ago
Splitting no information pop-up part of bug into bug 157885. I'll alter this bug
to be an enhancement request.
Severity: normal → enhancement


17 years ago
Depends on: 157885

Comment 5

17 years ago
Adjusting summary original summary was "file:// links sent from NS4.x do not
open in Mozilla or pop up an explaination"
Summary: file:// links sent from NS4.x do not open in Mozilla or pop up an explaination → [RFE] Allow graded access to file:// links within mailnews


17 years ago
Ever confirmed: true

Comment 6

17 years ago
Changing dependency to bug 157885 was duped against
Depends on: 84128
No longer depends on: 157885
Raising security to normal, the user should be able to click on a valid file url
link. Also set component to Security:General
Assignee: sspitzer → mstoltz
Severity: enhancement → major
Component: Mail Window Front End → Security: General
QA Contact: olgam → junruh
*** Bug 179511 has been marked as a duplicate of this bug. ***


17 years ago
QA Contact: junruh → bsharma
Any status on this bug?
Blocks: 132257

Comment 10

16 years ago
*** Bug 225425 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
Bug 233108 covers the more general case and has a patch.

*** This bug has been marked as a duplicate of 233108 ***
Last Resolved: 17 years ago16 years ago
Resolution: --- → DUPLICATE
This is different, imo... That bug's patch will let you give your mail messages
access to all files on your hard drive.  Doing so, imo, is stupid.  We need a
better setup for mail messages.
Depends on: 233108
Resolution: DUPLICATE → ---
*** Bug 266261 has been marked as a duplicate of this bug. ***
Product: MailNews → Core

Comment 14

14 years ago
*** Bug 301173 has been marked as a duplicate of this bug. ***
*** Bug 337581 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
The first part of a fix to this bug is probably implementing a way of checking if the file resides on a networked drive. AFAIK in non-windows environments this will be any link starting with file://///, in windows there is that but also networked drives which we should be able to determine using a call to GetDriveType

Comment 17

13 years ago
Suggestion: Track security level of operations requesting opening URL, modeling
after the Java privileged block API.

Hey, would the following idea address both sides of the 
problem (preventing arbitrary pages from requesting file:... 
URLs while allowing the user to request them)?

Java Privileged Block API

In Java, when some action requiring special priviledges is 
requested, the VM (effectively) scans the call stack back to 
some higher-privileged reference point and finds the lowest 
privilege level of all pending methods on the stack.  That 
privilege level is used to attempt the operation.

(For example:  A browser's general applet support code has 
privilege to open arbitrary connections.  When it loads an
applet's code, it gives the applet code privilege only to 
open connections to one host.  The socket-connection method 
checks the privilege of the call stack to decide whether to 
allow a connection. 

If the browser calls the connection method, the call stack 
has full privileges and any connection can be opened.  

When the browser invokes the applet, if the applet calls the 
connection method, the call stack has only limited privileges, 
and only certain connections may be opened.

Note that if the applet calls some miscellaneous support code 
in the browser and that code calls the connection method, 
the call stack _still_ has only limited privileges, because 
the stack contains one or more stack frames from the applet.

(There's also a way for browser code called from the applet to
regain higher-level privileges if needs them to perform some
action for the applet.)


For more information on this Java mechanism see 
http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html .

Applying To Mozilla/Seamonkey/Firefox

It seems that that kind of mechanism would be applicable to

The equivalent of the call stack would be a chain of actions
starting with a user input action (e.g., activating a link), 
going through various handling actions (e.g., invoking untrusted
Javascript), and extending down to each of the possibly multiple 
URL-loading actions indirectly triggered by the user input action.

Generally, user input actions (clicking on a button or link,
or entering a URL directly) would reset the privileges to 
the highest level. 

Handling actions would reduce the privilege level appropriately,
especially for actions that invoke or otherwise "listen to" 
untrusted code or data.

Consider several scenarios:

If the user clicks on a plain (non-Javascript) link, handling 
that click proceeds directly to trying to load the URL.  Since 
user actionshave full privileges, and there are no intervening 
handling steps that reduce the privileges, any URL can be loaded.

If the user clicks on a javascript: link, privileges are decreased
before executing the script, so that if execution of the script 
then tries to load a URL, the URL load is attempted only with the 
reduced privileges allowed for scripts (probably also according 
to the source of the page containing the script), and some URLs 
might not be loadable.

Similarly, the action of executing a script in a loaded page is 
a nested or chained action that has reduced privileges, as is
loading images in a page.

I think a model/mechanism like this could go a long way toward
making Mozilla rationale (not refusing to load file:.. URLs
directly requested by users) while allowing for security
concerns to be addressed.


Assignee: security-bugs → nobody
QA Contact: bsharma → security
OS: Windows XP → All
Hardware: PC → All
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.