Closed Bug 53493 Opened 24 years ago Closed 24 years ago
chrome html should get system principal
In an attempt to calm security fears, I restricted use of the system principal in chrome to .xul files only. This has caused problems for folks who put html files in chrome; I didn't realize the need here. Apparently the about:plugins code is broken because of this. I'm willing to give the system principal to html files, pending a chrome security review which I'll hold soon.
P1, because some features are broken.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → M19
nominated for nsbeta3+ to get about:plugins in for PR3/RTM. Note that if this got minus-ed, we should convert plugins.html to xul. Also, add dependency for
*** Bug 54237 has been marked as a duplicate of this bug. ***
Mitch, what is broken from the user perspective? I still see the plugins listed when using Mozilla bits, is this commercial only? Why would this need to go into the beta rather than just rtm? What is the risk?
go back and read my comment in 36908. I wound up giving up on localizing about:plugins and just checked in the old version from classic (presumably the one used for ages in 4.x). This bug would be necessary if we wanted to keep about:plugins as an html file and had to use string bundles from it. The about:plugins that is currently checked in works, but doesn't follow the localizability guidelines. The way to fix this is to either fix this bug and allow the use of string bundles in html files or to re-write about:plugins with xul. (right?). In the long term, maybe the latter is the best option. Didn't rginda have a component viewer working before? Is it a good idea to list plugins and components together? Sorry for the delayed reaction on this. i'm out this week.
I don't think this is critical enough to get into the branch for beta3 at this point. The plugin info comes up in a web page, and the English can be run through an online translator in a pinch. nsbeta3-, nominating for rtm.
Hyatt needs to bless this. Do we have any .html files in chrome that try to use XPConnect, etc.? This suddenly seems low priority, given the English-only HTML file that was checked in. If the right fix is to create about-plugins.xul, then we should not commit the patch in this bug, and encourage "chrome HTML". /be
I wrote: > we should not commit the patch in this bug, and encourage "chrome HTML". which should have read "not commit [...], thereby encouraging ...". IOW, if we can wait to do about-plugins.xul later, and we don't need system privileges for about-plugins.html now, then let's push off this bug, or close it WONTFIX. Hyatt, should we support privileged HTML in chrome? /be
html files in chrome have no system principal (XPConnect) access right now. Perhaps more damaging, html files in chrome have no access to the contents of chrome XUL documents. Apparently this is breaking the Transformiix/XSLT processor (bug 54237). Is this a priority? Are there any other html files in chrome which need XPConnect or DOM access to XUL documents? We might be breaking other chrome html that I don't know about. Checking in this fix doesn't change our security story significantly if at all, and it would solve some problems.
Wow, I didn't know XSL/T used HTML in chrome. LXR pointer? Someone please cough up a survey of chrome:....html files. /be
The current question is whether nsbeta3 can go out without this fix.
Well, is Transformiix truly busted without this fix? Does Netscape care about Transformiix working on PR3? Cc'ing nisheeth. /be
It would seem to be correct to allow any chrome documents (regardless of type) to have a system principal. However, I am curious why someone is using chrome HTML.
Of course they could be using chrome HTML in a content area, which would be reasonable. This is similar to what we do with FTP/file directory listings. They load in the content area but are still chrome URLs.
If all chrome file types should get the system principal, why are we bothering with the extension check for .xul or .xul and .html? Is it on account of .js files? Hrm. /be
Checking the file extension is not to fix any specific exploit, just an extra measure of security. Hyatt assured me that any files (.js files in particular) included in a xul or html page get the principal of the document. Just in case that isn't always the case, we assign system principals only to the document (xul or html) itself.
Fix checked in, trunk and branch. .xul, .html, and .xml extensions all get the system principal now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified per mstoltz's comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.