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)

x86_64
Windows 7
defect
Not set
normal

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.
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.
Ya I had this check removed on the first patch to the service ever, but I reverted that later.
Why?
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 :)
OK, then I think we should reintroduce that code.  :-)
Just for reference, one of the first intermediate patches: 
https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=481815&attachment=562962
> OK, then I think we should reintroduce that code.  :-)

Providing a cleaned up and tested version of that is what this task is for :)
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).
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.
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]
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?
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!
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.
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.
(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.
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.
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...
No. Also unfortunately, even regular Thunderbird release is based on ESR now because of lacking development resources :(
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... :)
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.
(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
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.
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
Adri, could you confirm that you're still working on this?
Flags: needinfo?(no52fear)
Yes I still want to work on this ticket if it's possible. I've been away for a little bit.
Flags: needinfo?(no52fear)
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.
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
This is the #1 reason I use Chrome. I hate always having an out-of-date Firefox.
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...
(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).
(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.
with an extension probably, but not via cmd or powershell that I know of.
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.
To me it just seems that the Mobile stuff is so important nowadays that desktop client gets forgotten.
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.
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.
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)
Just confirming that this still does not appear to be fixed.
Attached patch patch v1 (obsolete) — Splinter Review
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)
(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.
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)
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?
(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.
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.
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.
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.
Attached patch patch v2 (obsolete) — Splinter Review
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)
The write checks below if (!useService), are just indented.
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+
Attached patch patch v3 (obsolete) — Splinter Review
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)
(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);
Brian, checking in to make sure this won't be limited to just installations under program files.
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+
(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)
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.
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)
(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.
Attached patch patch v4Splinter Review
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)
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+
actually that whole line should be removed
argh sorry for the buspam, I see you just wanted to convert it to bool and I misread. This is fine as is
For us uninitiated, does being "pushed to oak" mean that it can be tested in the Nightly version now?  Or not?
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.
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!
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.
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
(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...
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)
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?
(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?
(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?
(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.
(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?
(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.
(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.
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" ?
(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...
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.
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!
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.
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
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 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.
(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.
(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.
(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.
(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.
Attached file Certificate and AppLocker Error (obsolete) —
(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?
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
(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.
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.
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+
Thanks for the updater patches Steffen, nice work!
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+
Attachment #786837 - Attachment mime type: text/plain → application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
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
(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.
https://hg.mozilla.org/mozilla-central/rev/13d42e9b36e2
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
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: --- → +
(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...
(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.
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.
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.
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...
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 :)
(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!
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.
QA Contact: alexandra.lucinet
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.
Limited users did not even see a UAC prompt. It is definitely a different issue. Please file a separate bug.
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
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.
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
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.
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.
Markus, I filed bug 969728 for you. Please do not add comments to closed bugs. It will be easily overlooked.
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.
@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.
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.
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!
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
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: