204476 - need fullPath in nsIDOMPlugin interface

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Pete Zha]

I think we need to add an attribute named fullPath in the nsIDOMPlugin interface.
Currently, we can get the full path from filename attribute but we need to set
the "plugin.expose_full_path" preference entry to "true".

In bug 185000, we need to return the plugin's fullPath to determine the current
Java installation the mozilla is using. But if I use filename attribute, I have
to set the "plugin.expose_full_path" to true first. So, the code is ugly.

So, it'd better to add attribute to satisfy such requirements.

Comment 1

[Pete Zha]

Attachment: patch (rejected by mls)

Here is a patch to add the attribute.
Note: I didn't tested it sinceI'm on vacation and my workspace haven't been
setuped.
alecf, Could you please take a look at this patch? Thanks!

Comment 2

[Alec Flett]

thanks for filing this, pete!

Comment 3

[timeless]

Attachment: alternative patch with junk mixed in

So this is sitting in my tree on boffo.

There are a few things i'm trying to do.
1. The pref dies. If you don't have XPConnect privs then you won't get the
fullpath.
2. If you want the fullpath then you get to QI to this other object.
This will allow about:plugins to show or not show the full path without
constructing lots of objects. (attachment 122488 [details] [diff] [review] leaves the other path as a
random choice)
I don't quite know how the reflection to untrusted js works which is why i'm
requiring the QI.
- the preceding relate to this bug, the following do not-
3. I'm working on caching plugins.
4. I'm working on a way to control which plugin is used for a mimetype.

I'm about to run off for a week, but i just wanted people to think about the
things that i've thought about before they make a change.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The reason we do not show the full path (and do not make it available to web
sites) is because that was considered a privacy/security violation.  Please do
NOT undo that change without getting review from Mitch.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Yes, please do not undo this change (thanks Boris). Please explain why you think
the full path (ass opposed to just the plugin name) is needed, and why that need
outweighs the loss of privacy caused by revealing a system configuration detail.

Comment 6

[Pete Zha]

Yes, I agree there are security issues. But I think maybe some where inside
mozilla need this. For example, in bug 185000, we need it to determine the
current plugin's path to tell user which java plugin the mozilla is using.
Currently, I have to set the pref to true and then use the filename attribute
and then set it back to old value. It's ugly as alecf said in bug 185000 comment 55.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

nsIDOMPlugin is accessible from scripts on Web pages, isn't it? I don't want any
full paths accessible from scripts in content. If you need this value internally
for bug 185000, add it to an interface that's not accessible from content.

You can do what you need to do without leaking potentially sensitive information.

Comment 8

[Anne (:annevk)]

Plugins are disabled and won't be coming back.