"Run As" dialog appears after every Nightly install

RESOLVED FIXED in mozilla12

Status

()

defect
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: bj, Assigned: bbondy)

Tracking

(Blocks 1 bug)

Trunk
mozilla12
x86_64
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

Posted image The Run As window
For the last couple of days I've been getting a "Run As" dialog appearing every time I update Nightly on 64-bit Windows XP. This happened at least once yesterday and twice today. I suspect this is related to bug 481815.

After I apply the update the small window saying something like "Nightly is being installed and will start sometime soon" with a progress bar appears and vanishes (as usual) then a "Run As" window appears just before the browser window appears.

After I click "OK" to the "Run As" window I noted a program named helper.exe vanished from the Task Manager Process list. (I couldn't see all the processes, so there also could have been changes in the W-Z section of the list.)
Component: Installer → Application Update
Product: Firefox → Toolkit
QA Contact: installer → application.update
Are you running as a limited user account?  Seems like it's from the prompt to install the maintenance service installer from limited user accounts.

Could you tell me the result of running:
sc query MozillaMaintenance?
(In reply to Brian R. Bondy [:bbondy] from comment #1)
> Are you running as a limited user account?

I don't know, how do I tell? (I'm heading home now, and won't be able to investigate this until Monday.)

> Could you tell me the result of running:
> sc query MozillaMaintenance?

[SC] EnumQueryServicesStatus:OpenService FAILED 1060:

The specified service does not exist as an installed service.
I also have this issue. Just to add another datapoint...

My account has administrator privileges. Running the command in cmd outputs

"[SC] EnumQueryServicesStatus:OpenService FAILED 1060: The specified service does not exist as an installed service."

The "Run As" dialog is triggered by "helper.exe" just after the updater finishes. Nightly starts normally without interacting with it.

Process explorer shows that the "Run As" window belongs to process "helper.exe" in path "Program Files\Nightly\uninstall\helper.exe", run with command-line arguments "argv0ignored /PostUpdate"
Sorry for the spam, just forgot to mention I'm on Windows XP SP3, 32bit.
John, did you get this more than once? And you clicked to run the application right?
I've been getting this for the past one or two builds if memory serves correctly, every time the updater finishes.

Right now I still have the "Run As" dialog open, I have not interacted with it in any way since updating 40 minutes ago. Clicking OK produces no result (example, the Mozilla Maintenance service being installed).
OK I've reproduced this on WinXP when obtaining the service from an update instead of from a previous new install.  It affects both admin and limited user accounts.

To get around this for now you can simply uncheck from that "Run as" dialog:

> [ ] Protect my computer and data from unauthorized program activity.

When that is checked it removed write access to the registry and we can't install the service.

After you run with that unchecked you won't get it anymore. 

Alternately you can wait for the fixed build which will auto correct your problem, but you'll have to keep closing those post-update run-as dialogs until then.
Output of "sc query MozillaMaintenance" after doing the above

SERVICE_NAME: MozillaMaintenance
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
                                (NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 1077       (0x435)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
Thanks for the info guys, I have it fixed, I'll attach a patch shortly.
Posted patch Patch v1. (obsolete) — Splinter Review
Assignee: nobody → netzen
Attachment #586635 - Flags: review?(robert.bugzilla)
Note for reviewer: For limited user accounts the maintenanceservice_installer won't be called from helper.exe /PostUpdate.
I know Fx Portable isn't officially supported by Mozilla, but I figured this also needs to mentioned for those that aren't already aware:

Also since the UAC change bug 481815 for those using a Firefox Portable version of Aurora 11.0a2 and Nighty 12.0a1(Created using zip builds), and you are using the Fx portable hidden config option setting to change 'firefox.exe' process name(example: firefoxaurora.exe), updates would download and fail to install. I had to revert the (firefoxaurora.exe and firefoxnightly.exe) both back to 'firefox.exe' and restore both of my Fx portable installations hidden config settings back to their defaults, so the updates would install without failing.

Note: I will be posting a bug soon on http://portableapps.com/forums/support/firefox_portable
re rob64rock@yahoo.com:

Could you post a new bug in bugzilla under toolkit/application update and CC me with the contents of Comment 12?

Also please answer the following question in that new ticket instead of answering here. 

Also if you can put any extra info or links about how to setup such a build that would be helpful to me. Thanks. 

> Also since the UAC change bug 481815 for those using a Firefox Portable 
> version of Aurora 11.0a2 and Nighty 12.0a1(Created using zip builds)

Are you sure about Aurora, the service from bug 481815 has not landed on Aurora yet.
Comment on attachment 586635 [details] [diff] [review]
Patch v1.

So, if the system has UAC disabled this will behave the same way on Win Vista and greater as it is on Win XP in this bug. There is code in toolkit/mozapps/installer/windows/nsis/common.nsh in ElevateUAC that checks if UAC is enabled (as long as it wasn't disabled or enabled during the current session) that should be used to check if UAC is enabled before using the runas verb.
Attachment #586635 - Flags: review?(robert.bugzilla) → review-
Comment on attachment 586635 [details] [diff] [review]
Patch v1.

Re-requesting review given the below information:

> So, if the system has UAC disabled this will behave the same way on Win 
> Vista and greater as it is on Win XP in this bug. 

I tested this on Vista and Win7 with all UAC levels and it is currently working correctly as is.  The runas verb will elevate if needed. If UAC is off, then the user is in essence already elevated.  The runas verb when UAC is off simply runs the program with no confirmation prompt on Vista and above.  The comment in the patch indicates this already so no change should be needed.
Attachment #586635 - Flags: review- → review?(robert.bugzilla)
What about a limited user with UAC disabled?
This code is currently gated by: 
> Call IsUserAdmin
> Pop $R0
> ${If} $R0 == "true"
So the installer is not executed for limited user accounts currently.
My concern is that iirc on Vista the runas verb when UAC is disabled will bring up the "run as a different user" UI for an administrator. This is what I recall from testing during the Firefox 2.0.0.2 cycle so I *might* be incorrect. On Windows 7 there is now an option to "Run as a different user" and a "Run as administrator" option which once again iirc is not available on Vista.
I tested this as is with each UAC level on both Vista and Win 7 and as per Comment 15 it does not do any prompt whatsoever. 

That being said, I can do your suggestion in Comment 14 if you prefer.
I'd feel better with that approach just in case.
Comment on attachment 586635 [details] [diff] [review]
Patch v1.

k will do.
Attachment #586635 - Flags: review?(robert.bugzilla)
Actually since this code only runs when IsUserAdmin is true, and the user has access to HKLM, would you be opposed to me just always simply calling:
nsExec::Exec "$INSTDIR\maintenanceservice_installer.exe"?

Then we would change this handling as per your comment 14 in bug 711475 (since we will probably want to loosen those checks there anyway).
I considered that a bit and think that I am fine with that though there might be edgecases I haven't thought of yet.
> I considered that a bit and think that I am fine with that though there 
> might be edgecases I haven't thought of yet.

I think we should be OK since we can only execute that code when we have HKLM, but I'll do comment 14 now since it'll need to be done eventually anyway.
Posted patch Patch v2. (obsolete) — Splinter Review
- Admin user account:
  - Windows 7 UAC off: GetElevationType returns 1, service installer runs and works, no prompt.
  - Windows 7 UAC on: GetElevationType returns 2, service installer runs and works, no prompt. 
  - Vista UAC off: GetElevationType returns 1, service installer runs and works, no prompt.
  - Vista UAC on: GetElevationType returns 2, service installer runs and works, no prompt. 
  - Win XP: Does not call GetElevationType, service installer runs and works, no prompt.
  - Windows 2000: Does not run service installer

- Limited user  account:
  - All OS: Does not run service installer because of HKLM check and IsAdmin call
Attachment #586635 - Attachment is obsolete: true
Attachment #590231 - Flags: review?(robert.bugzilla)
Posted patch Patch v3.Splinter Review
Per discussions on the phone, there may be edge cases with the split token detection approach (such as the user being a member of the backup operator group), so just try to run the app since we already have permissions.
Attachment #590231 - Attachment is obsolete: true
Attachment #590231 - Flags: review?(robert.bugzilla)
Attachment #590276 - Flags: review?(robert.bugzilla)
Attachment #590276 - Flags: review?(robert.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/9a67d6f21b3d
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.