Confirm
394
edits
Changes
Updated with latest information, mostly changes about x64.
The service security is modified with a special [http://msdn.microsoft.com/en-us/library/aa379298.aspx ACE] which allows non elevated processes to start and stop it. Setting these permissions on the service is needed because by default services can only be started and stopped by elevated processes. This is possible via the Win32 API [http://msdn.microsoft.com/en-us/library/windows/desktop/aa379589%28v=vs.85%29.aspx SetServiceObjectSecurity].
The service logs all operations of the last update, as well as taking a backup of the last 10 update operationsoperation logs
before it. The install process and update processes are logged separately. The logs live in %programdata%\Mozilla\logs.
Since the service executes an update via updater.exe in session 0, no UI is displayed. A An alternate implementation could have been to have the UI could be displayed display by running updater.exe with a user token from the service instead, but to avoid permission problems on files, and inconsistencies in different OS versions and user types, the update is always be run as session 0with the SYSTEM account.
== A single service and service versioning ==
If a service is already installed, the service will be replaced on updates and installs only if it is newer than what is installed. This means that if a user has Nightly installed, the Nightly service will be used to update all channels.
The service decides whether or not it is newer by looking at the updater file's version number in comparison to a new one being updated by application update or the installer.
* The service gets started
* The service determines which action should be performed from its command line parameters.
* If the command is an action other than a software update, the action is performed. (None are supported yet)
* If the command is a software update then continue on...
* The service verifies the updater.exe file (See section Signing builds below)
== When the service fails ==
* If there is an error creating the process, or during update, or a sign binary windows authenticode certificate check error, an error is written to update.status and info is reported via telemetry on the next restart of the callback application. The next restart of the callback application will also set the status back to pending so that the update will be applied next time without the service.* If there are more than 10 consecutive service specific errors(tracked with the app.update.service.errors pref), the service will automatically disable itself and reset this count to 0. A user can re-enable the service via preferences(app.update.service.enabled).
== Service as an optional component ==
* If the service is not installed, or disabled, we will fall back to the old way of updating: using updater.exeonly.* A user can chose choose to not install the service at install time of Firefox.
== Limited user accounts ==
The service will be installed for users automatically via application update. There are reasons why the service will not be installed via application update though:
* An OS lower than XP is being used (this also applies to the installer).
* The update is being performed as a limited user account (this also applies to the installer).
You can also control whether the installer installs the service using a [[Installer:Command_Line_Arguments|configuration ini]] method provided by the installer.
== Signing builds Verifying the updater is our own binary ==
To ensure we execute our own binary, we verify the signature of updater.exe to make sure it is signed by us.
