Closed
Bug 711475
Opened 13 years ago
Closed 11 years ago
Allow updates to be applied by limited user accounts into high integrity locations (such as program files)
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
FIXED
mozilla26
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 26+ |
People
(Reporter: bbondy, Assigned: steffen.wilberg)
References
Details
(Whiteboard: [mentor=bbondy][lang=c++][lang=js] (automatic updates work already))
Attachments
(3 files, 4 obsolete files)
Limited user accounts installed into Program Files currently (before and after bug 481815) do not get a prompt for installing the update. Even if you manually execute: const Cc = Components.classes; const Ci = Components.interfaces; Components.classes["@mozilla.org/updates/update-prompt;1"].createInstance(Components.interfaces.nsIUpdatePrompt).checkForUpdates(); You get a dialog that says you need to run the update from an account with permissions. We should enable this when the service is installed to work the same way as administrator and show an Apply Updates button. Perhaps we should always show it even if the service is not installed. If the user clicks the new Apply Now button under limited user accounts, and the user is not an admin, and the service is not being used, then a runas dialog should be displayed on XP and a limited account user UAC prompt on post XP.
Comment 1•12 years ago
|
||
I think this happens because gCanApplyUpdates <http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#339> is not aware of the service.
Reporter | ||
Comment 2•12 years ago
|
||
Ya I had this check removed on the first patch to the service ever, but I reverted that later.
Comment 3•12 years ago
|
||
Why?
Reporter | ||
Comment 4•12 years ago
|
||
Why was it removed? Not sure it was like the first day I started working on silent updates and I thought I should wait until later to remove this possibly important code :)
Comment 5•12 years ago
|
||
OK, then I think we should reintroduce that code. :-)
Reporter | ||
Comment 6•12 years ago
|
||
Just for reference, one of the first intermediate patches: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=481815&attachment=562962
Reporter | ||
Comment 7•12 years ago
|
||
> OK, then I think we should reintroduce that code. :-)
Providing a cleaned up and tested version of that is what this task is for :)
Comment 10•12 years ago
|
||
Now that the Windows service and the bgupdate through %LOCALAPPDATA% stuff are all done, is it possible to remove the limited user account roadblock? With the service enabled, there's nothing stopping any of the update steps from working in LUA, right? I think the only bit missing is a check for service availability in the about dialog, then it can go ahead instead of suggesting a manual download. I see there's a Patch (Comment 6), but I guess it's obsolete because it's unaware of the service and tries to use Runas/UAC instead (which was a bad idea anyway, especially for Windows XP where the Runas dialog can easily be spoofed).
Comment 13•12 years ago
|
||
I have Firefox deployed in an organization of about 1000 users. I would really love it if Firefox could silently update when the user account is not an administrator.
Reporter | ||
Comment 14•12 years ago
|
||
I'm going to be working with Adri over the next little while to figure out how this will be accomplished. We'll be testing on the Oak branch until we're ready to merge to m-c.
Assignee: netzen → no52fear
Whiteboard: [mentor=bbondy][lang=c++][lang=js]
Comment 16•12 years ago
|
||
Please understand that this is a serious security issue (not a mere bug). Consider the following scenario: A computer user is browsing unuder a non-admin Windows account. An admin logs into the computer only once every two or three months. Before admin comes, the user is browsing for several months with a vulnerable browser and is not notified that an update needs to be installed. Please fix this urgently. You have the system service in place, what are you waiting for?
Comment 17•12 years ago
|
||
Ian, everyone understands how important this feature is, but bug comments are not for putting pressure on devs that, as you can read on previous comments, are already looking for how to solve it. It's not like we had the solution and don't want to implement it ;) If you want to express that you consider this important, please use the voting feature bugzilla has (at the very top of this page). Thanks!
Comment 18•12 years ago
|
||
Dear Ruben, the point of my post was: This is incorrectly classified as a bug (or "feature"(!) as you wrote). It must be re-classified as a security issue. (And it is a shame that it has been known for months without being fixed.) Bug comments are very much for this kind of comments. On the contrary, YOUR type of posts is what does not belong to bug comments. Go troll somewhere else.
Comment 19•12 years ago
|
||
Ian, sorry if my previous message seems offensive to you, that wasn't my intention, I would ask you to be also respectful. This bugs is a new feature we don't have right now. Firefox was never able to update itself under non-privilege account (neither manually nor automatically) and we need to implement that as a new feature. Devs can give you a better a more technical view about this and what's classified as a security feature and what's not.
Comment 20•12 years ago
|
||
(In reply to Rubén Martín [:Nukeador] from comment #19) > This bugs is a new feature we don't have right now. Firefox was never able > to update itself under non-privilege account (neither manually nor > automatically) and we need to implement that as a new feature. Actually Firefox can update automatically under the Standard User account if the maintenance service is installed. But at the moment, users will have to remove all files under %localappdata%\Mozilla\Firefox\Mozilla Firefox\updates\0 after the update. It will be fixed since Firefox 18. Standard users can not update manually yet.
Reporter | ||
Comment 21•12 years ago
|
||
Hi guys, this bug is in progress but it was waiting on me for more information, we'll update when we have some more news. Adri and I are communicating via email. As a work around for now, you can install into your application data by canceling the UAC prompt when installing.
Comment 22•11 years ago
|
||
Question... When this bug is fixed, will Thunderbird 17.x ESR be able to take advantage of it as well? Or will we have to wait for the next Thunderbird ESR? Hoping the answer is the former, because having to manually update these via a Domain Admin account is frustrating...
Comment 23•11 years ago
|
||
No. Also unfortunately, even regular Thunderbird release is based on ESR now because of lacking development resources :(
Comment 24•11 years ago
|
||
Ok, well thanks for responding... Do you have any idea of the chances of this making it into TB 24 ESR then? No worries, if it doesn't it doesn't, but one can hope... :)
Comment 25•11 years ago
|
||
TB 24 ESR would be notified of updates by the background service. See comment #20. (It also applies to Thunderbird.) Manual updates from "About Thunderbird..." are not yet possible until this bug is fixed.
Updated•11 years ago
|
status-firefox-esr17:
--- → ?
Comment 26•11 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #20) > Actually Firefox can update automatically under the Standard User account if > the maintenance service is installed. But at the moment, users will have to > remove all files under %localappdata%\Mozilla\Firefox\Mozilla > Firefox\updates\0 after the update. It will be fixed since Firefox 18. I'm interested in getting silent background updates of minor Firefox and Thunderbird versions whilst people are logged in with Windows XP Limited accounts working. Masatoshi, can you please explain why users _have_ to remove these files after the update. Thanks
Comment 27•11 years ago
|
||
Because Firefox <= 17 failed to cleanup the files after the update. So we had to manually remove them on behalf of Firefox. Anyway, we don't have to remove the files anymore. The bug was fixed.
Comment 28•11 years ago
|
||
Granted, but you said "have to" so I was wondering what the fall out was from not doing so, unless you instead meant that it was just preferable to so that they weren't untidly left haning around. Presumably this is still relevant for Firefox 17 ESR, which is where I'm coming from. Thanks
Comment 29•11 years ago
|
||
Adri, could you confirm that you're still working on this?
Flags: needinfo?(no52fear)
Comment 30•11 years ago
|
||
Yes I still want to work on this ticket if it's possible. I've been away for a little bit.
Flags: needinfo?(no52fear)
Comment 31•11 years ago
|
||
How long is this going to take? We are currently rolling out Windows 7 in our Company and so far we are replacing Firefox with Google Chrome because of the Update Mechanism. Is there a way to trigger the Update via cmd/powershell? That way the update could be handled with a Scheduled Task that is running under the SYSTEM User.
Reporter | ||
Comment 32•11 years ago
|
||
We don't have a timeline set but you can already apply updates manually. Using the service is the same you just specify sc start MozillaMaintenance software-update and the arguments discussed on the wiki. https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
Comment 33•11 years ago
|
||
This is the #1 reason I use Chrome. I hate always having an out-of-date Firefox.
Comment 34•11 years ago
|
||
Seems to be working for us? I just had a call from someone that was looking at a prompt to update Firefox, and it worked...
Comment 35•11 years ago
|
||
(In reply to Charles from comment #34) > Seems to be working for us? I just had a call from someone that was looking > at a prompt to update Firefox, and it worked... As I already said in comment #20, Firefox >= 18 will notify of the update automatically. However, standard users can not run the update from [Help] > [About Firefox] yet. They will have to wait until Firefox notifies them (unless using the workaround written in comment #32).
Comment 36•11 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #35) > (In reply to Charles from comment #34) > > Seems to be working for us? I just had a call from someone that was looking > > at a prompt to update Firefox, and it worked... > > As I already said in comment #20, Firefox >= 18 will notify of the update > automatically. However, standard users can not run the update from [Help] > > [About Firefox] yet. They will have to wait until Firefox notifies them > (unless using the workaround written in comment #32). And is there a way to trigger this notification? Maybe via CMD/Powershell? Because the Update via MAR File is not what i am looking for.
Reporter | ||
Comment 37•11 years ago
|
||
with an extension probably, but not via cmd or powershell that I know of.
Comment 38•11 years ago
|
||
It's sad to see that nearly 1 1/2 year after being reported this issue still isn't fixed. I can't understand how Mozilla could decide to switch to "RapidRelease" without this feature.
Comment 39•11 years ago
|
||
To me it just seems that the Mobile stuff is so important nowadays that desktop client gets forgotten.
Comment 40•11 years ago
|
||
Mozilla is really leaving the Business Sector out. No update without administrative rights, no MSI from Mozilla and no ADMX File for Group Policy Configuration. And these are just some of the reasons why our company went with Google Chrome instead of Firefox. So please just fix the updating issue. Thank you.
Comment 41•11 years ago
|
||
You should perhaps be slightly more specific. If you refer to group policy management and managed installations you likely switched to Chrome for Business and not ordinary Chrome installation. Chrome installs to the user profile and is unmanageable like portable software. In security-sensitive environments execution of binaries from user data folders is forbidden anyway. In fact also Firefox can be installed like this by canceling the UAC dialog during initial installation. In managed environments most admins do not like auto-updating software as it might break corporate-webapp compatibility with each update. So here software is typically deployed. Here it's clearly a shame Mozilla does not provide MSI packages. I am using WPKG in such environments (not only due to Mozilla installers) to add a bit of deployment flexibility. The limitation to update Mozilla applications via about dialog is mainly blocking users with limited user privileges. Even worse, the current implementation is inconsistent. If Firefox 18+ during startup finds a new update it asks the user whether to update. If not canceled it uses the maintenance service and upgrades Firefox properly (even with limited privileges). However if the dialog is canceled and later the user opens help -> About Firefox then it just tells you that new updates are available, without even trying to check whether the maintenance service is available for an upgrade. When this is fixed then the ability of doing upgrades merely depend on the availability of the Mozilla Maintenance Service. If the service is there users should be able to perform upgrades either when offered during startup of Firefox or manually invoked in About dialog. At the moment oly one of them works properly. Likely this is done by copying 10 lines of code to the about dialog check but sadly this code was never approved yet leading to the strange situation that limited users now can perform an upgrade, but only if offered by Firefox but not via About dialog. In both cases system administrators could simply disable the maintenance service if automatic updates by non-privileged users are undesired.
Assignee | ||
Comment 42•11 years ago
|
||
To confirm comment 20, I just updated Firefox vom 21 to 22 on my limited user account on Windows 7. I got the *automatic* update prompt/dialog, which notified me of the update and let me download and apply/stage the update and then restart Firefox. I set the app.update.interval pref to a low value to trigger the dialog sooner. However, I couldn't update *manually* using the About Firefox dialog. It said I need to manually install updates.
Summary: Allow updates to be applied from limited user accounts when installed into program files → Allow updates to be applied from limited user accounts when installed into program files, after manually checking for updates using the About Firefox dialog (automatic updates work already)
Comment 43•11 years ago
|
||
Just confirming that this still does not appear to be fixed.
Assignee | ||
Comment 44•11 years ago
|
||
This is copied from getCanStageUpdates(). However, how can I test this? It doesn't use the service in my own build since it's not signed. Are try builds signed?
Assignee: no52fear → steffen.wilberg
Attachment #782203 -
Flags: feedback?(netzen)
Comment 45•11 years ago
|
||
(In reply to Steffen Wilberg from comment #44) > Created attachment 782203 [details] [diff] [review] > patch v1 > > This is copied from getCanStageUpdates(). > > However, how can I test this? It doesn't use the service in my own build > since it's not signed. Are try builds signed? There is no way that we've been able to test this case in part due to UAC having no way to override it for testing (which is completely understandable) as well as other similar reasons. Having said that, the path that isn't tested is primarily involving whether we have write permissions and the remainder is tested. Try builds are signed and you can disable signing locally for development. Uncomment out the following http://mxr.mozilla.org/mozilla-central/search?string=-DDISABLE_UPDATER_AUTHENTICODE_CHECK Just checking the pref is no where near enough. Off the top of my head, the service itself might not be installed, the service might be installed and manually disabled, it will need to fallback to some behavior (undecided as of yet) if the service is unable to update, and I am sure many more.
Reporter | ||
Comment 46•11 years ago
|
||
Comment on attachment 782203 [details] [diff] [review] patch v1 Review of attachment 782203 [details] [diff] [review]: ----------------------------------------------------------------- Awesome, thanks so much for the patch. There are a few other things we need to check though first. Once done, the easiest way to test is just for me to push to the oak branch and do 2 nightly builds from that. Both having your patch, the first one would update to the second one. ::: toolkit/mozapps/update/nsIUpdateService.idl @@ +423,5 @@ > readonly attribute boolean canCheckForUpdates; > > /** > * Whether or not the Update Service can download and install updates. > + * This is a function of whether or not the maintenance service is installed, nit: On Windows, this... is installed and enabled... ::: toolkit/mozapps/update/nsUpdateService.js @@ +577,5 @@ > + // No need to perform directory write checks, the maintenance service will > + // be able to write to all directories. > + LOG("gCanApplyUpdates - able to apply updates because we'll use the service"); > + // _sendServiceInstalledTelemetryPing() covers this case > + return true; We also need to check if the service is installed since the default pref is set to true. See: http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#l2245 Also we shouldn't have that define, but we should have this one: #ifdef MOZ_MAINTENANCE_SERVICE and this one: #ifdef XP_WIN We also need to check if the file is local, but we can maybe bypass this test if the fallback error that happens is fine as is. http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/updatehelper.cpp#l651 Ditto his one, let's try to test it and see what it looks like without doing it: http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#l2658 We can't return early here because there is some important stuff that needs to be done at the end of the function, in particular the hasUpdateMutex is still needed and submitHasPermissionsTelemetryPing(true) is still needed. Please set a var here to true if all conditions are met and then bypass the checks before those 2 calls.
Attachment #782203 -
Flags: feedback?(netzen)
Comment 47•11 years ago
|
||
Please clarify: are you looking for a fix that only enables users with limited accounts to update through help/about, or will the fix also make it possible to activate silent automatic updates, without any need for users to click somewhere?
Assignee | ||
Comment 48•11 years ago
|
||
(In reply to hartnegg from comment #47) > Please clarify: are you looking for a fix that only enables users > with limited accounts to update through help/about This bug is about the About Firefox dialog, nothing else. > or will the fix also make it possible to activate > silent automatic updates, without any need for users to click > somewhere? Background updates work already. To make them silent, without showing any dialog, go to about:config and set the pref app.update.silent to true. I haven't tried that myself yet though. If it doesn't work, please file a new bug or comment in bug 890770.
Comment 49•11 years ago
|
||
Background updates absolutely do not work. If you install Firefox on Windows into an account that is not an administrator then you get no updates. This is the only reason I use Chrome instead of Firefox.
Assignee | ||
Comment 50•11 years ago
|
||
Ben, that worked for me, see comment 42. But this is out of scope for this bug. You can file a new bug (https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Application%20Update). Enable the pref app.update.log and attach the log to the new bug.
Comment 51•11 years ago
|
||
Background updates only work if the users click on one of the two update notifications. If updates are switched to silent, then these notifications aren't shown, and then the updates don't work. Also if the users just don't click on the notifications, they also don't work. So theoretically they can work, but in most realistic situations they don't. The relevant bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=890770 So some of us are following the wrong bug.
Assignee | ||
Comment 52•11 years ago
|
||
Thanks for the quick feedback! > We also need to check if the service is installed since the default pref is > set to true. See: > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/ > nsUpdateService.js#l2245 OK, I've created a new isServiceInstalled() function out of that. However, how does this work for background updates? Do they check whether or not the service is installed? Because background updates already work on limited user accounts by using the service. > Also we shouldn't have that define, but we should have this one: > #ifdef MOZ_MAINTENANCE_SERVICE and this one: > #ifdef XP_WIN OK, but we don't need to #ifdef XP_WIN because you can't enable the MAINTENANCE_SERVICE on other platforms: http://dxr.mozilla.org/mozilla-central/source/configure.in#l6464 > We also need to check if the file is local, but we can maybe bypass this > test if the fallback error that happens is fine as is. > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/ > updatehelper.cpp#l651 > Ditto his one, let's try to test it and see what it looks like without doing > it: > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/ > updater.cpp#l2658 OK, I did nothing here :) > We can't return early here because there is some important stuff that needs > to be done at the end of the function, in particular the hasUpdateMutex is > still needed and submitHasPermissionsTelemetryPing(true) is still needed. > > Please set a var here to true if all conditions are met and then bypass the > checks before those 2 calls. Done.
Attachment #782203 -
Attachment is obsolete: true
Attachment #782303 -
Flags: feedback?(netzen)
Assignee | ||
Comment 53•11 years ago
|
||
The write checks below if (!useService), are just indented.
Reporter | ||
Comment 54•11 years ago
|
||
Comment on attachment 782303 [details] [diff] [review] patch v2 Review of attachment 782303 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the quick new patch, let's do one more round and then try pushing it to oak for testing. Almost there. > OK, I've created a new isServiceInstalled() function out of that. > However, how does this work for background updates? Do they > check whether or not the service is installed? > Because background updates already work on limited > user accounts by using the service. I'm not sure off hand why or if background updates work in this case, I guess some people are saying they do. Maybe we aren't doing the has access check for background updates. I'd like to test this once we get the next patch. ::: toolkit/mozapps/update/nsUpdateService.js @@ +1134,5 @@ > + * @return true if the service should be used for updates, > + * is installed and enabled. > + */ > +function isServiceInstalled() { > +#ifdef MOZ_MAINTENANCE_SERVICE We do want an #ifdef XP_WIN here but we don't want #ifdef MOZ_MAINTENANCE_SERVICE in this exact case. That's because the service can still be installed even if the build we're using doesn't support it. @@ -2241,5 @@ > - * is installed. > - * Also submits a telemetry ping with a boolean value which indicates if the > - * service was at some point installed, but is now uninstalled. > - */ > - _sendServiceInstalledTelemetryPing: function AUS__svcInstallTelemetryPing() { Let's keep this function and just call into isServiceInstalled() and then report it's value for telemetry. Then we can use isServiceInstalled without reporting to telemetry each time. If you want you can split it up into 2 functions isServiceInstalled and wasServiceInstallAttempted. @@ +2563,5 @@ > this._sendBoolPrefTelemetryPing(PREF_APP_UPDATE_SERVICE_ENABLED, > "UPDATER_SERVICE_ENABLED"); > this._sendIntPrefTelemetryPing(PREF_APP_UPDATE_SERVICE_ERRORS, > "UPDATER_SERVICE_ERRORS"); > + isServiceInstalled(); nit: back to this._sendServiceInstalledTelemetryPing();
Attachment #782303 -
Flags: feedback?(netzen) → feedback+
Assignee | ||
Comment 55•11 years ago
|
||
Done, done, and done. I used a global gServiceAttempted to pass the second value around. I had no luck applying a complete update on the nightly channel though, it fails with "error 19".
Attachment #782303 -
Attachment is obsolete: true
Attachment #782854 -
Flags: feedback?(netzen)
Assignee | ||
Comment 56•11 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #54) > Comment on attachment 782303 [details] [diff] [review] > I'm not sure off hand why or if background updates work in this case, I > guess some people are saying they do. In onStopRequest, there's this code: if (Components.isSuccessCode(status)) { if (this._verifyDownload()) { state = shouldUseService() ? STATE_PENDING_SVC : STATE_PENDING; shouldUseService() just checks the pref and nothing else. There's also this code, in handleUpdateFailure: // As a safety, when the service reaches maximum failures, it will // disable itself and fallback to using the normal update mechanism // without the service. if (failCount >= maxFail) { Services.prefs.setBoolPref(PREF_APP_UPDATE_SERVICE_ENABLED, false); Services.prefs.clearUserPref(PREF_APP_UPDATE_SERVICE_ERRORS);
Comment 57•11 years ago
|
||
Brian, checking in to make sure this won't be limited to just installations under program files.
Reporter | ||
Comment 58•11 years ago
|
||
Comment on attachment 782854 [details] [diff] [review] patch v3 Review of attachment 782854 [details] [diff] [review]: ----------------------------------------------------------------- Thanks again, a couple more nits, sorry we're really really close though. I'm pretty sure this will be enough to get thing working. (In reply to Steffen Wilberg from comment #56) > (In reply to Brian R. Bondy [:bbondy] from comment #54) > > Comment on attachment 782303 [details] [diff] [review] > > I'm not sure off hand why or if background updates work in this case, I > > guess some people are saying they do. > > In onStopRequest, there's this code: > if (Components.isSuccessCode(status)) { > if (this._verifyDownload()) { > state = shouldUseService() ? STATE_PENDING_SVC : STATE_PENDING; > > shouldUseService() just checks the pref and nothing else. > There's also this code, in handleUpdateFailure: > // As a safety, when the service reaches maximum failures, it will > // disable itself and fallback to using the normal update mechanism > // without the service. > if (failCount >= maxFail) { > Services.prefs.setBoolPref(PREF_APP_UPDATE_SERVICE_ENABLED, false); > Services.prefs.clearUserPref(PREF_APP_UPDATE_SERVICE_ERRORS); Yep this second one is just protection against using the service in case of some horrible bug or multiple security attack attempts. The first one should attempt to use the service, but I wasn't sure if something else went wrong somewhere in between. I just tried this myself now though and it works without the about dialog, so this patch should be enough to cover all cases. ::: toolkit/mozapps/update/nsUpdateService.js @@ +254,5 @@ > const PING_BGUC_ADDON_HAVE_INCOMPAT = 30; > > var gLocale = null; > +#ifdef XP_WIN > +var gServiceAttempted = 0; I'd prefer not to have this global variable. Let's either split that function in 2 or return 2 values from the function: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Multiple-value_returns @@ +575,5 @@ > } > } > > + let useService = false; > +#ifdef MOZ_MAINTENANCE_SERVICE shouldUseService will always return false when MOZ_MAINTENANCE_SERVICE is defined so you can remove this define. @@ +1136,5 @@ > + * > + * @return true if the service should be used for updates, > + * is installed and enabled. > + */ > +function isServiceInstalled() { nit: getServiceInstalledValues and return [installed, attempted]; or split function in two. @@ +1153,5 @@ > + installed = wrk.readIntValue("Installed"); > + wrk.close(); > + } catch(e) { > + } > + LOG("isServiceInstalled - installed = "+installed+", attempted = "+gServiceAttempted); nit: Please put spaces before and after each binary operator. Break lines with the operator on the previous line. LOG("isServiceInstalled - installed = " + installed + ", attempted = " + gServiceAttempted); @@ +2287,5 @@ > * Also submits a telemetry ping with a boolean value which indicates if the > * service was at some point installed, but is now uninstalled. > */ > _sendServiceInstalledTelemetryPing: function AUS__svcInstallTelemetryPing() { > + let installed = isServiceInstalled(); // also sets gServiceAttempted nit: remove comment
Attachment #782854 -
Flags: feedback?(netzen) → feedback+
Reporter | ||
Comment 59•11 years ago
|
||
(In reply to Robert Strong [:rstrong] (do not email) from comment #57) > Brian, checking in to make sure this won't be limited to just installations > under program files. Yep I don't think there's anything program files specific, just a bad bug title, I'll update now. Let me know if you know of something off hand though. But I'll test both ways once we get this patch on oak.
Summary: Allow updates to be applied from limited user accounts when installed into program files, after manually checking for updates using the About Firefox dialog (automatic updates work already) → Allow updates to be applied from the about dialog for limited user accounts into high integrity locations (such as program files)
Whiteboard: [mentor=bbondy][lang=c++][lang=js] → [mentor=bbondy][lang=c++][lang=js] (automatic updates work already)
Comment 60•11 years ago
|
||
No problem, I just wanted to make sure this doesn't land with restrictions for program files like there are for the elevate with UAC checks which are needed.
Comment 61•11 years ago
|
||
Brian, one last thing, this should "just work" when applying an update from the app update UI or if no UI is shown. I'm going to change the summary to reflect that but if there is a reason why it can only apply to when UI is shown feel free to change it back though I would like to know why there is this restriction. Thanks!
Summary: Allow updates to be applied from the about dialog for limited user accounts into high integrity locations (such as program files) → Allow updates to be applied by limited user accounts into high integrity locations (such as program files)
Reporter | ||
Comment 62•11 years ago
|
||
(In reply to Robert Strong [:rstrong] (do not email) from comment #61) > Brian, one last thing, this should "just work" when applying an update from > the app update UI or if no UI is shown. I'm going to change the summary to > reflect that but if there is a reason why it can only apply to when UI is > shown feel free to change it back though I would like to know why there is > this restriction. Thanks! I tested with a current m-c build without this patch and got the little popup prompt on the bottom, I clicked it and applied the update to program files through the update wizard. So that already worked. I haven't tried to just leave it without that UI and have it apply in the background but I think that also works. So the work in this bug is just to get the rest of the updates to work from limited user accounts, which I think the only thing remaining is the about dialog. I'm fine with the title either way though.
Assignee | ||
Comment 63•11 years ago
|
||
Thanks for the suggestion of multiple return values, but would prevent my from using "if (isServiceInstalled())", because that would return Object, which is always "true". So I split the function in two. Since the check for Attempted is only needed for Telemetry, I left it in _sendServiceInstalledTelemetryPing. I also fixed the other nits. So the question remains if we want to use the new isServiceInstalled() function in other places as well, like the one I mentioned in comment 56.
Attachment #782854 -
Attachment is obsolete: true
Attachment #785296 -
Flags: review?(netzen)
Reporter | ||
Comment 64•11 years ago
|
||
Comment on attachment 785296 [details] [diff] [review] patch v4 Review of attachment 785296 [details] [diff] [review]: ----------------------------------------------------------------- > So the question remains if we want to use the new isServiceInstalled() > function in other places as well, like the one I mentioned in comment 56. I think those are ok, the updater which uses the service when pending-service will fall back to just the updater when it's not installed and the other checks are made. The reason we want to check it here is because we want to know before starting the update so we can display the appropriate UI. I'm going to push this (with the nit change) to oak. Please feel free to update the patch in the meantime if you want to, or wait for the results of the oak testing. ::: toolkit/mozapps/update/nsUpdateService.js @@ +1144,5 @@ > + installed = wrk.readIntValue("Installed"); > + wrk.close(); > + } catch(e) { > + } > + installed = installed == 1; nit: installed = 1 only
Attachment #785296 -
Flags: review?(netzen) → feedback+
Reporter | ||
Comment 65•11 years ago
|
||
actually that whole line should be removed
Reporter | ||
Comment 66•11 years ago
|
||
argh sorry for the buspam, I see you just wanted to convert it to bool and I misread. This is fine as is
Comment 67•11 years ago
|
||
For us uninitiated, does being "pushed to oak" mean that it can be tested in the Nightly version now? Or not?
Reporter | ||
Comment 68•11 years ago
|
||
I tested a basic update through the about dialog with a limited user account and it works great. If anyone wants to help test this out more, you can download and install this build for testing: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-08-03-04-02-04-oak/firefox-25.0a1.en-US.win32.installer.exe Some ideas for testing: For each of these cases: 1. limited user account installed in program files 2. limited user account installed in root of c:\ 3. limited user account installed into users profile directory via canceling uac prompt on installation 4. admin account in program files Run these tests, Test that the update reacts as expected...: i) via about dialog w/ MozillaMaintenance service installed & enabled ii) via about dialog w/ service not installed, but enabled pref (about:config app.update.service.enabled) iii) via about dialog w/ service not installed, but enabled pref iv) via about dialog w/ service installed & not enabled v) Test that background updates work vi) What happens when explorer has the installation directory open, make sure it still works. vii) test to make sure stage updates being disabled still works app.update.staging.enabled to false. If you do run some tests please feel free to update the bug with testing results.
Assignee | ||
Comment 69•11 years ago
|
||
Hah, mid-air with Brian! But I've written a more step-by-step guide, so I'll post anyway: (In reply to Jason from comment #67) > For us uninitiated, does being "pushed to oak" mean that it can be tested in > the Nightly version now? Yes, you can test the "Nightly-Oak": 1. Set Options - Advanced - Update - Never check for updates, in order to prevent automatic background updates, and test the path via the About dialog. 2. Go to about:config and set app.update.log to true. 3. Download this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-08-02-17-56-32-oak/firefox-25.0a1.en-US.win32.installer.exe 4. Run the installer, choose Custom, install it into a new directory like "C:\Program Files (x86)\Firefox Nightly Oak". Exit every instance of Firefox/Beta/Aurora/Nightly. 5. Run the oak nightly and open Web Developer->Browser Console. Click its Clear button. 6. Now go to Help->About Nightly and click "Check for Updates". 7. Watch the Browser Console. Expected log output is, between other content: [19:26:21.303] AUS:SVC gCanApplyUpdates - bypass the write checks because we'll use the service [19:26:21.303] AUS:SVC gCanApplyUpdates - able to apply updates ... [19:26:38.062] AUS:SVC Downloader:onStopRequest - setting state to: pending-service [19:26:38.072] AUS:SVC getCanStageUpdates - able to stage updates because we'll use the service [19:26:38.072] AUS:SVC Downloader:onStopRequest - attempting to stage update: Nightly 25.0a1 [19:26:46.922] AUS:SVC readStatusFile - status: applied, path: C:\Users\Steffen\AppData\Local\Mozilla\updates\C57028AA954C105E\updates\0\update.status [19:26:46.937] AUS:SVC UpdateManager:refreshUpdateStatus - Notifying observers that the update was staged. state: applied-service, status: applied 8. Now click the Restart button --> Firefox restarts with the new version. 9. Open the Browser Console. That should contain [19:28:50.723] AUS:SVC readStatusFile - status: succeeded, path: C:\Users\Steffen\AppData\Local\Mozilla\updates\C57028AA954C105E\updates\0\update.status 10. Open the About dialog. Note the build date is now 2013-08-03 (or newer). I installed on Windows 7 from my administrator account, and tested on a normal (limited) user account. The update succeeded there without popping up a Windows UAC dialog. Further testing is needed and highly appreciated!
Comment 70•11 years ago
|
||
Success: I tested 2013-08-03-04-02-04-oak in XP with these two config changes: app.update.silent=true and app.update.interval=60. It updated itself to 2013-08-04 without any user interaction. In a second try help/about was also able to install the update, requiring just one click to allow the restart. Any chance that this can also be implemented in version 24? This would permit you to issue a press release together with the new ESR, maybe getting some users back to Firefox.
Comment 71•11 years ago
|
||
Side question... Will this work (many many thanks for getting this done!!) result in the upcoming Thunderbird ESR (24) also being able to silently update as well? Or is there more TB specific work that will need to be done? If the latter, is there already a bug open to track it (none show in the blockers)? Thanks again, Charles
Comment 72•11 years ago
|
||
(In reply to hartnegg from comment #70) > Any chance that this can also be implemented in version 24? This would > permit you to issue a press release together with the new ESR, maybe getting > some users back to Firefox. This would be huge, imho... and even more so if the same can be done for *both* Firefox *and* Thunderbird...
Assignee | ||
Comment 73•11 years ago
|
||
Comment on attachment 785296 [details] [diff] [review] patch v4 >+ installed = installed == 1; I'll add a comment "// convert to bool"
Attachment #785296 -
Attachment description: 711475-gCanApplyUpdates.diff → patch v4
Attachment #785296 -
Flags: review?(netzen)
Comment 74•11 years ago
|
||
How does this fit into that wiki page about silent updates https://wiki.mozilla.org/Program_Management/Programs/Silent_Update Is the wiki page incomplete and/or outdated, or is it talking about something different? Should it be updated, or removed?
Comment 75•11 years ago
|
||
(In reply to Steffen Wilberg from comment #69) > Hah, mid-air with Brian! But I've written a more step-by-step guide, so I'll > post anyway: > >...... >...... > > Further testing is needed and highly appreciated! Just tested this Version on Windows 7 with a normal (limited) user account: 1. limited user account installed in program files i) via about dialog w/ MozillaMaintenance service installed & enabled ... vii) test to make sure stage updates being disabled still works app.update.staging.enabled to false. I tried every possible Test Scenario when installed in program files, unfortunately none of it worked. I got the following Output: [13:31:03.506] AUS:SVC Downloader:onProgress - progress: 33600556/33600556 [13:31:03.513] AUS:SVC Downloader:onStopRequest - original URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-03-05-09-40-oak/firefox-25.0a1.en-US.win32.complete.mar, final URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-03-05-09-40-oak/firefox-25.0a1.en-US.win32.complete.mar, status: 0 [13:31:03.513] AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 10, retryTimeout: 2000 [13:31:03.514] AUS:SVC Downloader:_verifyDownload called [13:31:03.514] AUS:SVC Downloader:_verifyDownload downloaded size == expected size. [13:31:04.838] AUS:SVC Downloader:_verifyDownload hashes match. [13:31:04.850] AUS:SVC Downloader:onStopRequest - setting state to: pending-service [13:31:04.869] AUS:SVC getCanStageUpdates - able to stage updates because we'll use the service [13:31:04.869] AUS:SVC Downloader:onStopRequest - attempting to stage update: Nightly 25.0a1 [13:33:10.482] AUS:SVC isServiceInstalled = true [13:33:10.484] AUS:SVC readStatusFile - status: pending-service, path: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status Normal (limited) user accounts only have the right to read & execute in the Program Files Folder. When i started Firefox as Admin it worked right away. Am i doing something wrong?
Assignee | ||
Comment 76•11 years ago
|
||
(In reply to Alexander Lackner from comment #75) > [13:31:04.850] AUS:SVC Downloader:onStopRequest - setting state to: > pending-service > [13:31:04.869] AUS:SVC getCanStageUpdates - able to stage updates because > we'll use the service > [13:31:04.869] AUS:SVC Downloader:onStopRequest - attempting to stage > update: Nightly 25.0a1 > [13:33:10.482] AUS:SVC isServiceInstalled = true > [13:33:10.484] AUS:SVC readStatusFile - status: pending-service, path: > C: > \Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\upda > te.status Hmm, I would have expected the status to be "applied-service" instead of "pending-service". Have you set app.update.staging.enabled back to true? What happens if you follow steps 8 (restart) and 9 (check the Browser Console) of comment 69? What does the line "AUS:SVC readStatusFile - status:" say? Did you use the administrator account to install Nightly, then switch to the limited account, and try to update from the limited account?
Comment 77•11 years ago
|
||
(In reply to hartnegg from comment #74) > How does this fit into that wiki page about silent updates > https://wiki.mozilla.org/Program_Management/Programs/Silent_Update > > Is the wiki page incomplete and/or outdated, or is it talking about > something different? Should it be updated, or removed? We used to use wiki pages for project management back in 2011 and we no longer are using them so nothing needs to be done.
Comment 78•11 years ago
|
||
(In reply to Steffen Wilberg from comment #76) > Did you use the administrator account to install Nightly, then switch to the > limited account, and try to update from the limited account? Should this matter? All of our computers have the apps installed by a Domain Admin account, then Limited User accounts use the apps. I'm hoping you aren't suggesting silent auto updates won't be supported like this?
Assignee | ||
Comment 79•11 years ago
|
||
(In reply to Charles from comment #78) > All of our computers have the apps installed by a Domain Admin account, then > Limited User accounts use the apps. That is what this bug is about primarily! And it should work in the other scenarios listed in comment 68 as well. I'm just trying to find out the failure from comment 75.
Comment 80•11 years ago
|
||
(In reply to Steffen Wilberg from comment #76) > (In reply to Alexander Lackner from comment #75) > Hmm, I would have expected the status to be "applied-service" instead of > "pending-service". Have you set app.update.staging.enabled back to true? > > What happens if you follow steps 8 (restart) and 9 (check the Browser > Console) of comment 69? What does the line "AUS:SVC readStatusFile - > status:" say? > > Did you use the administrator account to install Nightly, then switch to the > limited account, and try to update from the limited account? app.update.staging.enabled was always set to true. i never get the button to restart, it always just says "applying update..." but if i restart manually i just get an error that the update could not be applied. Output from Browser Console after restart: [08:12:16.196] AUS:SVC Creating UpdateService [08:12:16.207] AUS:SVC gCanCheckForUpdates - able to check for updates [08:12:16.207] AUS:SVC isServiceInstalled = true [08:12:16.207] AUS:SVC gCanApplyUpdates - bypass the write checks because we'll use the service [08:12:16.207] AUS:SVC gCanApplyUpdates - able to apply updates [08:12:16.207] AUS:SVC readStatusFile - status: pending-service, path: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status [08:12:16.249] AUS:SVC handleFallbackToCompleteUpdate - install of complete or only one patch offered failed. [08:12:16.376] UTM:SVC TimerManager:registerTimer - id: browser-cleanup-thumbnails [08:12:16.580] AUS:UI gUpdates:onLoad - setting current page to startpage errors [08:12:16.589] AUS:UI gErrorsPage:onPageShow - update.statusText: The Update could not be installed (patch apply failed) [08:12:17.004] AUS:SVC isServiceInstalled = true [08:12:17.004] AUS:SVC getLocale - getting locale from file: resource://gre/update.locale, locale: en-US [08:12:17.005] AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130802175632/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml [08:12:17.005] AUS:SVC Checker: checkForUpdates, force: false [08:12:17.005] AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130802175632/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml [08:12:17.006] AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130802175632/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml [08:12:17.103] PAC file installed from http://myproxy [08:12:17.142] NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindow.localStorage] @ about:home:101 [08:12:18.456] AUS:SVC Checker:onLoad - request completed downloading document [08:12:18.457] AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130802175632/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml [08:12:18.458] AUS:SVC Checker:onLoad - number of updates available: 1 [08:12:18.459] AUS:SVC UpdateService:_selectAndInstallUpdate - add-on compatibility check not performed due to the update version being the same as the current application version, just download the update [08:12:18.459] AUS:SVC Creating Downloader [08:12:18.459] AUS:SVC UpdateService:_downloadUpdate [08:12:18.460] AUS:SVC readStringFromFile - file doesn't exist: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status [08:12:18.460] AUS:SVC readStatusFile - status: null, path: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status [08:12:18.483] AUS:SVC Downloader:downloadUpdate - downloading from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-03-05-09-40-oak/firefox-25.0a1.en-US.win32.complete.mar to C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.mar ... Yeah that is exactly what i did.
Assignee | ||
Comment 81•11 years ago
|
||
Thanks. Please use the "Add an attachment" link at the top of this bug to attach log files rather than pasting as a comment, to keep the bug readable.
> i never get the button to restart, it always just says "applying update..." but
> if i restart manually i just get an error that the update could not be applied.
I would expect to find an error in the log in that case, before the restart.
What does the log show after the line
AUS:SVC Downloader:downloadUpdate - downloading from" ?
Comment 82•11 years ago
|
||
(In reply to Steffen Wilberg from comment #81) > I would expect to find an error in the log in that case, before the restart. > What does the log show after the line > AUS:SVC Downloader:downloadUpdate - downloading from" ? [08:12:19.297] AUS:SVC Downloader:onStartRequest - original URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-03-05-09-40-oak/firefox-25.0a1.en-US.win32.complete.mar, final URI spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/08/2013-08-03-05-09-40-oak/firefox-25.0a1.en-US.win32.complete.mar [08:12:19.336] AUS:SVC Downloader:onProgress - progress: 5057/33600556 ... And then it repeats the whole process of updating...
Assignee | ||
Comment 83•11 years ago
|
||
Yeah, it downloads the update again. But what comes after that? Could you please attach a complete log, with using the About dialog, until it says "Applying update..." and the things that come after that.
Reporter | ||
Comment 84•11 years ago
|
||
Please also attach a zip containing the logs in C:\ProgramData\Mozilla\logs. It's best if you delete all the logs in there first, and then try to reproduce after that. And then if there are logs that show up, attach them in a zip to this bug. Thanks!
Comment 85•11 years ago
|
||
Tried the Update again and captured the Output from the Browser Console. It failed completely after the second restart and did not even load the update. Logs in "C:\ProgramData\Mozilla\logs" where there before the failed update, i added them to the zip file. There were no new log files after the update failed.
Assignee | ||
Comment 86•11 years ago
|
||
Thanks. The last failure is because of this: [14:24:08.601] aus3.mozilla.org:443 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Might be a problem with your network proxy. You should be able to view this XML file in Firefox without any security warning: https://aus3.mozilla.org/update/3/Firefox/25.0a1/20130802175632/WINNT_x86-msvc/en-US/nightly-oak/Windows_NT%206.1.1.0%20%28x64%29/default/default/update.xml The other logs don't seem to tell what goes wrong. The first one ("update.xlsx") downloads the full update (complete.mar) and then ends with this: [14:01:49.218] AUS:SVC Downloader:_verifyDownload hashes match. [14:01:49.229] AUS:SVC Downloader:onStopRequest - setting state to: pending-service [14:01:49.245] AUS:SVC getCanStageUpdates - able to stage updates because we'll use the service [14:01:49.246] AUS:SVC Downloader:onStopRequest - attempting to stage update: Nightly 25.0a1 -- [14:03:44.683] UTM:SVC TimerManager:notify - notified timerID: browser-cleanup-thumbnails -- [14:05:44.703] UTM:SVC TimerManager:notify - notified @mozilla.org/browser/search-service;1 I'm missing the "AUS:SVC readStatusFile" line though. After a restart, the second log ("update after restart.xlsx") shows that the update is still "pending-service": [14:06:39.140] AUS:SVC readStatusFile - status: pending-service, path: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status It then downloads the same complete.mar again, tries to stage the update, but ends with "pending-service": [14:08:35.686] AUS:SVC Downloader:_verifyDownload hashes match. [14:08:35.698] AUS:SVC Downloader:onStopRequest - setting state to: pending-service [14:08:35.714] AUS:SVC getCanStageUpdates - able to stage updates because we'll use the service [14:08:35.715] AUS:SVC Downloader:onStopRequest - attempting to stage update: Nightly 25.0a1 [14:08:39.281] AUS:SVC isServiceInstalled = true [14:08:39.282] AUS:SVC readStatusFile - status: pending-service, path: C:\Users\testuser\AppData\Local\Mozilla\updates\EEFEA8717BC47F65\updates\0\update.status [14:08:39.282] UTM:SVC TimerManager:notify - notified @mozilla.org/updates/update-service;1
Assignee | ||
Comment 87•11 years ago
|
||
Uh oh, your maintenanceservice.log has thie line at the end: *** Warning: Not enough command line arguments to execute a service command*** Brian or Robert, any idea?
Assignee | ||
Comment 88•11 years ago
|
||
This is C:\ProgramData\Mozilla\logs\maintenanceservice.log from my work machine. This is how it should look like if the service succeeds in updating Firefox.
Reporter | ||
Comment 89•11 years ago
|
||
(In reply to Steffen Wilberg from comment #87) > Uh oh, your maintenanceservice.log has thie line at the end: > *** Warning: Not enough command line arguments to execute a service > command*** > > Brian or Robert, any idea? This usually indicates that the user double clicked maintenanceservice.exe, or ran it manually with not enough command line arguments. I'm guessing it was the former.
Reporter | ||
Comment 90•11 years ago
|
||
(In reply to Charles from comment #71) > Side question... > > Will this work (many many thanks for getting this done!!) result in the > upcoming Thunderbird ESR (24) also being able to silently update as well? > > Or is there more TB specific work that will need to be done? > > If the latter, is there already a bug open to track it (none show in the > blockers)? > > Thanks again, > > Charles Not likely, it will land in Firefox release #26, but the changes are to common code shared by TB. Updater changes are very risky in nature so they don't get uplifted often.
Reporter | ||
Comment 91•11 years ago
|
||
(In reply to Alexander Lackner from comment #85) > Created attachment 786242 [details] > log files for update error > > Tried the Update again and captured the Output from the Browser Console. It > failed completely after the second restart and did not even load the update. > > Logs in "C:\ProgramData\Mozilla\logs" where there before the failed update, > i added them to the zip file. There were no new log files after the update > failed. If you delete the directory completely where the logs are stored, do any new ones appear throughout the entire testing? I think maybe the one maintenanceservice.log file is old from double clicking the exe or something like that.
Comment 92•11 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #90) > Updater changes are very risky in nature so they > don't get uplifted often. This is relative. Leaving silent automatic updates broken for another full ESR cycle is also a risk. If you backport this to version 24 (next ESR), you could ask on the enterprise mailing list for help to quickly run further tests, because many people there are waiting for this feature.
Comment 93•11 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #91) > If you delete the directory completely where the logs are stored, do any new > ones appear throughout the entire testing? I think maybe the one > maintenanceservice.log file is old from double clicking the exe or something > like that. Today i did not get Nightly to even download the update, i get an error before that. We have our own Issuing CA in the company and so the Certificate Checks for the Issuer throw an Error which interrupts the Update Process as seen in the attachment. This check could be a major Problem for bigger companies. The bug from yesterday is something different. For security reasons, users in our Domain are only allowed to execute files in C:\Program Files (x86). In the AppLocker Eventlog i found that Firefox tried to execute updater.exe in %OSDRIVE%\USERS\TESTUSER\APPDATA\LOCAL\MOZILLA\UPDATES\EEFEA8717BC47F65\UPDATES\0\ under the context of my User who does not have the right to execute files here. Can't the maintenance service run this exe as the SYSTEM user?
Assignee | ||
Comment 94•11 years ago
|
||
Alexander, these are two separate problems. The certificate problem looks like bug 770594. Please follow up there or file a new bug. I haven't found a bug about the second problem. Could you please file a new bug about that? https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Application%20Update
Comment 95•11 years ago
|
||
(In reply to hartnegg from comment #92) > (In reply to Brian R. Bondy [:bbondy] from comment #90) >> Updater changes are very risky in nature so they >> don't get uplifted often. > This is relative. Leaving silent automatic updates broken for another full > ESR cycle is also a risk. If you backport this to version 24 (next ESR), you > could ask on the enterprise mailing list for help to quickly run further > tests, because many people there are waiting for this feature. I agree wholeheartedly. I am one of those who work for a smaller company, and don't have the budget for the proper tools to administer/automate software updates, so having both Firefox and Thunderbird being able to keep themselves updated without me having to intervene would be one less headache for me to deal with. Having to wait another full year would not be a happy making thought.
Reporter | ||
Comment 96•11 years ago
|
||
We release every 6 weeks, and there are 4 channels, so it would be a few months max in worst case. Someone can request with a flag on the patch that this be uplifted past the Nightly builds, but the call is not up to me. It would go to release driver and they can make a decision. For now we just need to get it landed on mozilla-central for Nightly builds though, this is the first step no matter what happens.
Reporter | ||
Comment 97•11 years ago
|
||
Comment on attachment 785296 [details] [diff] [review] patch v4 My testing seems to work great, I tried in both limited user accounts and admin accounts installed program files and inside a directory without permissions inside c:\. I only tried with win8 but I don't think it would be too much different with other OS'. > The bug from yesterday is something different. For security reasons, > users in our Domain are only allowed to execute files in > C:\Program Files (x86). In the AppLocker Eventlog i found > that Firefox tried to execute updater.exe in > %OSDRIVE%\USERS\TESTUSER\APPDATA\LOCAL\MOZILLA\UPDATES\EEFEA8717BC47F65\UPDATES\0\ > under the context of my User who does not have the right to > execute files here. Can't the maintenance service run this > exe as the SYSTEM user? The reason we don't execute the updater.exe inside program files, is because it's in use to do the update. When the maintenance service is in use here is the sequence of events: 1. Firefox executes updater.exe to do the upddate inside appdata (low integrity process) 2. Low integrity updater.exe asks the maintenance service to do an update 3. maintenance service copies updater.exe inside the maintenance service directory inside program files. 4. maintenance service executes updater.exe inside the maintenance service to do the update. Perhaps you could configure it to only allow executing high integrity processes inside program files, but allow low integrity processes to execute anywhere, then the issue would go away. If not please file a new bug and we can discuss it there. This bug in particular is just to get it working with limited user accounts w/o extra restrictions like having to execute binaries inside program files.
Attachment #785296 -
Flags: review?(netzen)
Attachment #785296 -
Flags: review+
Attachment #785296 -
Flags: feedback+
Reporter | ||
Comment 98•11 years ago
|
||
Thanks for the updater patches Steffen, nice work!
Assignee | ||
Comment 99•11 years ago
|
||
Comment on attachment 785296 [details] [diff] [review] patch v4 Thanks for the quick reviews! http://hg.mozilla.org/integration/fx-team/rev/13d42e9b36e2
Attachment #785296 -
Flags: checkin+
Assignee | ||
Updated•11 years ago
|
Attachment #786837 -
Attachment mime type: text/plain → application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Assignee | ||
Comment 100•11 years ago
|
||
Comment on attachment 786837 [details] Certificate and AppLocker Error [09:14:35.322] Expected certificate attribute 'issuerName' value incorrect, expected: 'OU=Equifax Secure Certificate Authority,O=Equifax,C=US', got: 'E=test@company.com,CN=COMPANY-ISSUING-CA,...'. @ resource://gre/modules/CertUtils.jsm:106 This is bug 770594.
Attachment #786837 -
Attachment is obsolete: true
Comment 101•11 years ago
|
||
(In reply to Steffen Wilberg from comment #94) > I haven't found a bug about the second problem. Could you please file a new > bug about that? > https://bugzilla.mozilla.org/enter_bug. > cgi?product=Toolkit&component=Application%20Update Filed bug 902771.
Comment 102•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/13d42e9b36e2
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment 103•11 years ago
|
||
Release note should read something like "Firefox updates now support Windows limited user accounts in high integrity locations like Program Files." Feel free to suggest better wording if you have it. Thanks.
relnote-firefox:
--- → +
Updated•11 years ago
|
Comment 104•11 years ago
|
||
(In reply to Asa Dotzler [:asa] from comment #103) > Release note should read something like "Firefox updates now support Windows > limited user accounts in high integrity locations like Program Files." Feel > free to suggest better wording if you have it. Thanks. Well, in XP they are called Limited Accounts. In Vista/7 this was changed to 'Standard' Accounts, and now with Windows 8, you have 'Standard' accounts which are now also called 'Local', and you also have the ability to log in with an email address, which, I just learned, syncs all of your apps and settings on up to 5 different (Windows 8) computers... which is actually kind of cool. So, this would also have to be tested with that new kind of 'Connected' account type. Has this been tested on Windows 8/8.1 at all yet? But in a Corporate environment, the most important would be the local Standard account. Now to find a way to completely disable 'Connected' accounts on corporate PCs...
Comment 105•11 years ago
|
||
(In reply to Charles from comment #104) > Well, in XP they are called Limited Accounts. In Vista/7 this was changed to > 'Standard' Accounts, and now with Windows 8, you have 'Standard' accounts > which are now also called 'Local', and you also have the ability to log in > with an email address, which, I just learned, syncs all of your apps and > settings on up to 5 different (Windows 8) computers... which is actually > kind of cool. > > So, this would also have to be tested with that new kind of 'Connected' > account type. > > Has this been tested on Windows 8/8.1 at all yet? > > But in a Corporate environment, the most important would be the local > Standard account. > > Now to find a way to completely disable 'Connected' accounts on corporate > PCs... Well, I don't even think the account type even matters, does it? Since your "account type" is really dictated by which group(s) your account is part of. In other words, the privileges and permissions of an account and its associated groups is what really matters, not the supposed account type. If a "limited user" or "standard user" has been given additional permissions, then this bug would not affect them.
Comment 106•11 years ago
|
||
My main point was that 'Standard' is the more correct term, seeing as XP is so very old *and* the only one to call them 'Limited' accounts (well, it and Windows 200, which is even older). Also - I didn't say anything about 'granting extra privileges' to these kinds of accounts, so no idea why you made that comment.
Comment 107•11 years ago
|
||
Whoa, buddy. Defensive much? I was not aware that every single point that I made in reply to you had to be in direct relation to something you said. Must be a new rule. In any case, my point was that I do not know if calling them *anything* -- whether "limited" or "standard" -- is really precise enough. Like I said, a so-called "limited user" or "standard user" would have rights to "Program Files" or other directories if given those permissions by an administrator, thus muddying the waters about which accounts would benefit from this bug fix. I guess if we want to call them "limited" or "standard" accounts for shorthand, that's fine, but it does not really get at the true heart of the problem of the bug: a lack of permissions.
Comment 108•11 years ago
|
||
Defensive? What about my reply made you think I was being defensive? I was just pointing out that your comment - which, in case you didn't notice, really only had *one* point - made no sense in context. Also, just because an Administrator *can* add extra privileges doesn't mean they will or do - and my opinion is that in the vast majority of cases, they do *not* modify these permissions, so, yes, the type of account *is*, in the vast majority of cases, significant. And since 'Standard' is what Microsoft calls them, then 'Standard' is what we should call them. All that said, it is really not a large concern of mine, so feel free to advocate calling them whatever you want...
Comment 109•11 years ago
|
||
Windows has more than two kinds of account, all with different default permissions... I came up against this issue because of accounts which are members of the user group. As Jason correctly states the group the user is in is irrelevant - the bug is that code that checks whether a user has write permissions to the install location isn't allowing the update service which is there for that very reason to be invoked. Charles is correct that on one account control panel Windows 7 refers to them as "Standard User (Users Group", "Administrator (Administrators Group)" and "Other: [dropdown box]". The simple account creation pane on XP refers to them differently however. It's hardly worth arguing over though! My suggestion for wording would be something like "Updates can now be performed by users without write permissions to Firefox install directory (requires Mozilla Maintenance Service)" That way you don't have to list every possible account type able to initiate the maintenance service :)
Comment 110•11 years ago
|
||
(In reply to alistair from comment #109) > Windows has more than two kinds of account, all with different default > permissions... > > I came up against this issue because of accounts which are members of the > user group. As Jason correctly states the group the user is in is irrelevant > - the bug is that code that checks whether a user has write permissions to > the install location isn't allowing the update service which is there for > that very reason to be invoked. > > Charles is correct that on one account control panel Windows 7 refers to > them as "Standard User (Users Group", "Administrator (Administrators Group)" > and "Other: [dropdown box]". The simple account creation pane on XP refers > to them differently however. > > It's hardly worth arguing over though! > > My suggestion for wording would be something like "Updates can now be > performed by users without write permissions to Firefox install directory > (requires Mozilla Maintenance Service)" > > That way you don't have to list every possible account type able to initiate > the maintenance service :) Your suggestion is pretty much exactly what I would suggest, as well. That really explains the heart of the problem. Having said that, if someone wants to go the "limited" or "standard" way for simplicity's sake, that's fine, as well. Not a big deal either way!
Updated•11 years ago
|
Updated•11 years ago
|
status-firefox-esr17:
? → ---
Comment 111•11 years ago
|
||
Nominating for esr24 tracking because when we get closer to our next esr release (32, I believe) we'll want to give notice to deployments that this is included.
tracking-firefox-esr24:
--- → ?
Updated•11 years ago
|
QA Contact: alexandra.lucinet
Updated•10 years ago
|
tracking-firefox-esr24:
? → ---
Comment 113•10 years ago
|
||
Is this absolutely confirmed to be fixed? I have not done any additional testing, but I just tried updating to release 27 from release 26 using the "About Firefox" dialog, and I was met with a UAC prompt requesting administrative privileges for the Firefox updater. Just some background: --The Mozilla Maintenance Service is installed and enabled --Firefox is set to "Automatically install updates" --Firefox is set to "Use a background service to install updates" The issue could, of course, be with the computer itself (like I said, I have done no additional testing just yet), but I wanted to throw this out there in case anyone else has had the issue.
Comment 114•10 years ago
|
||
Limited users did not even see a UAC prompt. It is definitely a different issue. Please file a separate bug.
Comment 115•10 years ago
|
||
Hi, several years we are waiting for the Mozilla Firefox Update Service to Update Firefox for limited Standard Users. Yes i have a Software Management Solution, and yes deploy a "Firefox XY.exe -ms" is not a big deal. Its not "set-it-and-forget-it" though. I tried to Update from 26 to 27 with a Standard user from the Help Menu. After restarting it still shows Version 26 with the "restart to Update" Button. I read about 2 ways of Updating 1. via Help Menu 2. automatic update. How can i verify / Trigger automatic updates? Is there any tweak i could try? (write permission in Program Folder for standard users is not sufficient - it then creates the "updated" Folder with Contents but still keeps the old Version.) thanks Markus
Assignee | ||
Comment 116•10 years ago
|
||
Markus, please make sure you have Firefox installed by an admin into the standard program file directory, like C:\Program Files (x86)\Mozilla Firefox, and that the maintenance service is installed as well (which is the default). Don't grant write permissions for that directory to the limited user account; it's the purpose of the maintenance service, which has the necessary permissions, to write to the install directory. You can download older releases like Firefox 26 from ftp://releases.mozilla.org/pub/mozilla.org/firefox/releases/ Set the pref app.update.log to true and watch the Browser Console while checking for updates. If the problem persists, file a new bug and CC me. Attach the Browser Console log to the new bug.
Comment 117•10 years ago
|
||
Hi Steffen, there is no Error and no message in the Browser Console regarding Update. It simply keeps saying "restart to Update" and stays with Version 26. If i delete the updates Folder and active-update.xml and updates.xml it Downloads again. If i login as Administrator Update works. best regards Markus
Comment 118•10 years ago
|
||
update: there was a GPO configured to Automatically deny elevation requests for Standard users. If i disable the GPO i get the UAC Prompt for Admin credentials. Not an alternative for a students Lab Installation.
Comment 119•10 years ago
|
||
It is possible to update as standard user using this command: sc start MozillaMaintenance software-update software-update "..updater.exe" "." "%PROGRAMFILES(x86)% ... (http://superuser.com/questions/691218/how-to-allow-non-admins-to-update-firefox) Not Practicable for me it is still easier to deploy via softwa distributuion. In former Versions of Firefox the user could not update. The Help-Update-Dialog was greyed out. Now (since Version 26 i believe) the users see the Button but Ffox wont invoke the command above.
Comment 120•10 years ago
|
||
Markus, I filed bug 969728 for you. Please do not add comments to closed bugs. It will be easily overlooked.
Comment 121•10 years ago
|
||
not a Mozilla issue! I found the updater work with standard user. what breaks the updater must be some Folder redirection stuff in our mandatory Profile.
Comment 122•10 years ago
|
||
@Jason, are you using mandatory Profiles? In my case Firefox wont use maintenance Service if the Profile is mandatory. (In reply to Jason from comment #113) > Is this absolutely confirmed to be fixed? > > I have not done any additional testing, but I just tried updating to release > 27 from release 26 using the "About Firefox" dialog, and I was met with a > UAC prompt requesting administrative privileges for the Firefox updater. > > Just some background: > > --The Mozilla Maintenance Service is installed and enabled > --Firefox is set to "Automatically install updates" > --Firefox is set to "Use a background service to install updates" > > The issue could, of course, be with the computer itself (like I said, I have > done no additional testing just yet), but I wanted to throw this out there > in case anyone else has had the issue.
Comment 123•10 years ago
|
||
I'm trying to get my head around this bug... If this bug "is about the About Firefox dialog, nothing else", merely covering the case where people using Limited / Restricted / Standard user accounts use Help -> About to perform the update, and that automatic updates whilst such users were logged in were already viausing the Mozilla Maintenance Service, then should this bug more correctly be thought of as 'Allow updates (by the Firefox program, rather than the Mozilla Maintenance Service) to be applied by limited user accounts into high integrity locations (such as program files)'? The way I think of updates, when I think of 'Firefox' performing the update, I don't see any differentiation between 'Firefox' and the 'Mozilla Maintenance Service' and similarly people don't appear to make the distinction when they talk in forums such as this, though I'm starting to suspect that we should.
Comment 124•10 years ago
|
||
Pete, it isn't just about the about dialog and Firefox initiates the update performed by maintenance service. Having said that, if you are experiencing a bug please file a new bug. Thanks!
Comment 125•10 years ago
|
||
Thanks Robert, I'm not experiencing a particular bug I'm trying to understand this issue in advance of deployment. As I understand it then, both Firefox and the Mozilla Maintenance Service require this bug be fixed in order for auto update to work for those account types; so admins using the ESR channel need to wait for Firefox 31 ESR for this feature. Is that correct? Thanks
Comment 126•10 years ago
|
||
Yes
Comment 127•10 years ago
|
||
Given the first time this capability became available for Firefox ESR was in version 31, does this now exist in Thunderbird 31 also? The 'Thunderbird Bug Fixes' list at https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/buglist.html hasn't yet been updated for 31 and only lists changes in 24. I don't know how to otherwise find this information. Thanks.
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•