Closed Bug 352762 Opened 18 years ago Closed 17 years ago

XPInstall Vista Permission problems

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Version:
1.8 Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dougt, Assigned: benjamin)

References

Details

Attachments

(3 files, 1 obsolete file)

Allow installers/launchable things in PFS, rev. 1
14.46 KB, patch
doronr
: review+
dveditz
: approval1.8.1.12-
Details | Diff | Splinter Review
UI suckiness on mac
145.91 KB, image/png
Details
Close downloaded file output streams on finish, rev. 1
1.44 KB, patch
Details | Diff | Splinter Review
Under Vista, XPInstall can no longer install into any protected parts of the system such as c:\program files\. Although this was a problem under XP, it is now much more serious -- even as a admin account, I can not write into Program Files with Firefox (using xpinstall). Plugins that our offered off of the plugin finder service which install into Program Files no longer work and file with a -202 error (sometimes you will see a -211 error, but looking at the log, it is really a -202). I am not sure how or why our updater.exe can successfully install into Program Files during an update. It might be that Vista is using some sort of heuristics which enables updater.exe to work while restricting Firefox.
DougT, Software Update doesn't use XPInstall which is why it works... perhaps Core -> Installer: XPInstall Engine for the install.js style extensions and the 1.5.0.x and below installer if they both exhibit this problem.
i am pretty sure software update would fail if it tryied to write into program files. Moving this bug to the right component.
Component: Software Update → Installer: XPInstall Engine
Product: Firefox → Core
Version: 2.0 Branch → 1.8 Branch
(In reply to comment #2) > i am pretty sure software update would fail if it tryied to write into program > files. Moving this bug to the right component. I thought I read a bug comment from you regarding updater.exe requesting elevated privs and then when elevated privs were granted it worked though the OS displayed that it was unsigned, etc.
exactly -- updater does just that -- it asks the user to upgrade authorization to admin. For whatever reason, firefox (xpinstall) does not do this.
QA Contact: software.update → xpi-engine
Cool, that means software update is in good shape since it doesn't use xpinstall.
(if software update tries to install into protected areas of the disk, it will also fail)
(In reply to comment #4) > exactly -- updater does just that -- it asks the user to upgrade authorization > to admin. For whatever reason, firefox (xpinstall) does not do this. So, when software update ran in your test where updater asked for permission you were running as admin, it just plain failed, or something else?
there are two cases: 1) running xpinstall or software update and trying to write/copy files into c:\program files. This fails without any vista dialog. xpinstall issues the -202 error as I mentioned above. I believe this is because Vista doesn't see Firefox as an "installer" app. 2) running updater.exe This works fine, but vista does present a dialog confirming that you want to run/install.
(In reply to comment #8) ... > 2) running updater.exe > > This works fine, but vista does present a dialog confirming that you want to > run/install. There are also post update operations performed in nsPostUpdateWin.js that need admin access.
> I am not sure how or why our updater.exe can successfully install into Program > Files during an update. It might be that Vista is using some sort of > heuristics which enables updater.exe to work while restricting Firefox. Correct; Vista looks at various heuristics to determine if an app needs to be elevated to admin level prior to launch (and generally, any exe with "update" in its name meets this criteria. The XPInstall issue is a serious one that will need nontrivial work to function correctly under Vista; as other people have pointed out, an app running at normal permissions under Vista does not have the rights to modify the Program Files directory. To make XPInstall work properly under Vista, you need to either provide another plugin directory in the current user's directory (which is writable), or spawn a separate .exe at elevated permission (which requires user authentication). IMHO the second is preferable since it keeps the existing folder structure, and also meets the general Vista user experience of "installing software of any sort requires a UAC authentication". The Adobe Flash Player team is very interested in the resolution of this bug and when a fix might be planned.
I agree, i would prefer the second. However, I think we should consider asking Microsoft to add us to the list of applications that can update the system -- with user interaction of course... (we all should think long and hard about this)
Let's think about this for a second. We could ditch xpinstall altogether except for some legacy XPIs that we continue to need to support, which are mainly plugin installers provided by the plugin-finder service. If these XPIs could use an internal setup.exe program, or could be packaged as extensions (which is currently possible but not really used), we could stop supporting xpinstall in general.
I think this is an alternative -- but what happens when "software update" wants to install global extensions?
(In reply to comment #13) > I think this is an alternative -- but what happens when "software update" wants > to install global extensions? Software update handles global extensions the same way that it handles the app.
meaning that if you want to install global extensions via any code in Firefox, the same problem will exist.
(In reply to comment #15) > meaning that if you want to install global extensions via any code in Firefox, > the same problem will exist. No, that means that when using software update to update a global extension that it uses the mechanism provided by software update. This doesn't negate your statement of "if you want to install global extensions via any code in Firefox, the same problem will exist."
In case it isn't clear from comment #1 - Software Update does not use xpinstall. Also from your comments it appears that Software Update works but even if it doesn't it wouldn't be specific to global extensions since Software Update uses the same mechanism for updating the entire app including global extensions, etc.
Rob, thanks for pointing this out. The bug really is: Under vista, ANY code in Firefox that tries to write into unwritable parts of the system for the given user - for any reason - will fail. There is no real solution until Microsoft unblocks Firefox (& thunderbird, etc.)
Just to be clear... does that negate your comment #4? I thought that was working? (In reply to comment #4) > exactly -- updater does just that -- it asks the user to upgrade authorization > to admin. For whatever reason, firefox (xpinstall) does not do this. There are other solutions besides asking Microsoft to one-off Firefox so that it prompts the user... I believe there are API's we can call to request elevated privs as other app's have to or we can have a separate exe as noted in comment #10
(In reply to comment #18) > Rob, thanks for pointing this out. The bug really is: > > Under vista, ANY code in Firefox that tries to write into unwritable parts of > the system for the given user - for any reason - will fail. > > There is no real solution until Microsoft unblocks Firefox (& thunderbird, > etc.) No, there is a real solution, which is to spawn a process at elevated permissions which can do the install. This requires user authentication under UAC, but IMHO this is a good thing, as it reinforces to the user that something requires admin rights to install executable code. Asking Microsoft to unblock Firefox and Thunderbird is probably a good idea for existing versions, but it's unlikely they'd put in such an exemption for anything other than the current versions... future versions will likely have to adapt to the Vista restrictions.
right. another solution is to move our installer technologies and other "stuff" that has to write to these locations out of the Firefox exe.
*** Bug 354723 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Let's think about this for a second. We could ditch xpinstall altogether except > for some legacy XPIs that we continue to need to support, which are mainly > plugin installers provided by the plugin-finder service. If these XPIs could > use an internal setup.exe program, or could be packaged as extensions (which is > currently possible but not really used), we could stop supporting xpinstall in > general. I am leaning more towards this than any of the other possible solutions. I am concerned though about supporting a subset of xpinstall since we would introduce the same types of problems as happened when the EM was introduced in that we had xpi's that were EM managed and xpi's that were not EM managed which led to quite a bit of confusion.
*** Bug 362388 has been marked as a duplicate of this bug. ***
Cygwin project had similar problems. Please see http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1020271&SiteID=1&mode=1 and the solution proposal by David Tyler Hunt (using manifest file)
> The XPInstall issue is a serious one that will need nontrivial work to function > correctly under Vista; as other people have pointed out, an app running at > normal permissions under Vista does not have the rights to modify the Program > Files directory. To make XPInstall work properly under Vista, you need to > either provide another plugin directory in the current user's directory (which > is writable), or spawn a separate .exe at elevated permission (which requires > user authentication). > > IMHO the second is preferable since it keeps the existing folder structure... I don't agree with you. I would prefer the first solution. IMHO Firefox really misbehaves in this case. Why should Firefox install XPIs globally? From a security point of view, Firefox should avoid installing any software system wide if not really necessary! I agree with you that browser updates must be installed in the program directory, but not XPIs. Each user should have the possibility to decide which plugins/extensions he want to use. Therefore it only makes sense to me to create a plugins folder for each user in it's home directory. This would not change the folder structure too much, because Firefox already uses a directory for configuration files in the user's home directory. Creating a plugins folder in the user's directory would also improve the usability under linux. It has always been a pain in the ass under linux that normal users are not able to install plugins without starting the browser as root.
I agree that plug-ins should be a per-user decision. For plug-ins that have COM components and other system-level bits (e.g. Marc Gueury's latest HTML tidy extension) Firefox should elevate the process when it is required. There are a few good starting point resources that talk to how to do this here: http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/default.aspx http://msdn2.microsoft.com/en-us/library/aa480152.aspx http://www.codeproject.com/useritems/VistaElevator.asp Since moving to Windows Vista I've been able to work and develop as a non-admin. It's been great and I wouldn't want to spoil it or lose a great extension to it.
Flags: blocking1.9?
Just tested: This problem still occurs on Windows Vista Home Premium with Firefox 2.0.0.2 installed.
If this isn't something we can do for 2.0.0.x users, then we should come up with a more convenient work around for the PFS problem, like sniffing UA and handing directly off to the Plug-in provider's download page. Right now, for example, installing Flash for Vista is an ugly experience that's not at all rational for the end user.
Flags: blocking1.8.1.4?
Why don't we just ask Adobe to package flash as an extension? all these plugins that install using install.js should be contacted and asked to update.
(In reply to comment #32) > Why don't we just ask Adobe to package flash as an extension? all these plugins > that install using install.js should be contacted and asked to update. Would we still be able to install the plugins without prompting the user to restart, for 2.0.0.x users? I'm not sure how that decision is made within the PFS client code or EM or wherever, but if we can resolve that then I am very much in favour of this plan.
Flash is rather the exception here given it's a small single .dll and not a big bloated application. But yes, we should auto-discover new plugins if the user visits about:plugins or a page calls window.plugins.refresh(true).
Well, the problem currently is that we don't actually install the plugin extension until we restart. However, as long as there isn't a previous version we should be able to install immediately, update the dirlist, and call plugins.refesh(). This sounds like too much for FF20x, unfortunately. We should definitely scope it for FF3. To solve the "large installed app" problem, can't we just skip xpinstall and run an executable?
Needs a workable trunk solution before we can judge the scope of risk on the branch.
Flags: blocking1.8.1.4? → wanted1.8.1.x+
I am the developer at Adobe responsible for our existing plugin installers, including the XPI that does not work on Vista. I am more than happy to make whatever changes are needed. We can respond within a very short period to make changes. We value the existing Firefox install experience for Flash Player a great deal, and we will do whatever it takes to get things up an running on Vista. Feel free to contact me directly [michael(at)adobe.com].
Assignee: dougt → benjamin
For the record, here is what Rob Strong and I discussed for this bug: 1) Give PFS the ability to download and run native installers and not just XPI packages. This will hopefully be backport to the branch fairly easily. 2) Remove support for install.js-style xpinstall. This will be trunk-only and if it doesn't make it for FF3 that's ok, but old-style xpinstall is permanently broken on Windows Vista and we should stop supporting it. I hope to have part 1 up this week.
Status: NEW → ASSIGNED
This doesn't work right yet. I'm having problems with nsIDownloader corrupting the file download. For example, I'm downloading a 33MB file and the progress notifications say 12345678 of 33111222, but when I get the downloadcompleted notification the file is only 22MB large. Is this perhaps related to the use of the default/cache location instead of an explicitly-specified location?
ok, this does everything I want except that the UI still sucks a little bit. It's worst on mac: when you .launch a DMG, finder opens it in the background behind Firefox, so it's completely unclear that you're supposed to go run the installer and come back later.
Attachment #269195 - Attachment is obsolete: true
Attachment #269501 - Flags: review?(doronr)
Attached image UI suckiness on mac —
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 looks good to me
Attachment #269501 - Flags: review?(doronr) → review+
I forgot about this patch, but it is necessary in order to close the fileoutpustream when we finish downloading. Otherwise Windows refuses to launch the file.
Attachment #273818 - Flags: review?(cbiesinger)
Comment on attachment 273818 [details] [diff] [review] Close downloaded file output streams on finish, rev. 1 I've already reviewed a patch for this problem in bug 263127
Attachment #273818 - Flags: review?(cbiesinger)
I checked this in on trunk. I also marked blocking1.9? on bug 263127 so that this code is actually useful. I'll file a followup on AMO/PFS server to actually start using it.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 263127
> 2) Remove support for install.js-style xpinstall. This will be trunk-only and > if it doesn't make it for FF3 that's ok, but old-style xpinstall is permanently > broken on Windows Vista and we should stop supporting it. Are there any other bugs about this other than bug 299041 and maybe bug 380000? Where should people trying to use install.js be directed?
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 I forgot to ever get this landed on branch... it would help make Java installation from PFS better.
Attachment #269501 - Flags: approval1.8.1.11?
Attachment #269501 - Flags: approval1.8.1.10?
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 more than we want to rush into 2.0.0.10 right now.
Attachment #269501 - Flags: approval1.8.1.10?
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 approval-minus for 1.8.1.12, it's not clear we should be "improving" a mechanism we're taking away in the next version and still won't work entirely well. It's a potentially risky change for something we're not seeing a lot of complaints about
Attachment #269501 - Flags: approval1.8.1.12? → approval1.8.1.12-
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 Dan, can you reconsider? This is a change to PFS that allows us to *not* use xpinstall, but rather native installers. We are certainly not removing this feature in 1.9
Attachment #269501 - Flags: approval1.8.1.12- → approval1.8.1.12?
And this is a big deal for Sun and the Java installer.
I wish this bug can be fixed. Currently, I must launch Firefox with "run as administrator" under Vista, otherwise I can't install some plugins. It's a boring thing, isn't it?
Comment on attachment 269501 [details] [diff] [review] Allow installers/launchable things in PFS, rev. 1 Please come up with a combined, tested, branch patch. Given recent branch-breaking releases we're reluctant to approve patches piecemeal
Attachment #269501 - Flags: approval1.8.1.12? → approval1.8.1.12-
Is there any place in the wiki that enumerates values for installerHash? Does it follow the same hashMethod:hashValue pairing as in AUS and AMO? Example: sha1:fb43af5af11bbe2eff0a8e21ca6db67f8ba75290
Mike, it uses the same values and codepath as XPIHash, and I'm pretty sure that 'sha1:fb...' is the correct format.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: