969728 - Standard users cannot update Firefox if Mandatory Profile is used

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Masatoshi Kimura [:emk]]

See bug 711475 comment #115 and following comments.

Comment 1

[Masatoshi Kimura [:emk]]

@Markus:
1. What version of Windows are you using? (Vista, 7, 8, or 8.1?)
2. Could you tell me "EnableLUA", "ConsentPromptBehaviorAdmin", and "PromptOnSecureDesktop" values under the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" key using Regitry Editor?

Comment 2

[Markus Wehr]

Thanks. it must be a configuration issue. I found the updater working on a freshly installed pc. (clean user Profile more exactly)

The UAC GPOs (machine specific) are not involved in the issue.

we use a mandatory Profile. Also Folder redirection.

I believe i need to correct an issue with the mandatory Profile to fix this. (perhaps some Folder redirection stuff - "user Shell Folders" values or "Shell Folders")

Do you know exactly what check Firefox does to decide wheather or not to use maintenance Service?

In my case the update button Triggers UAC Prompt when it shouldnt.

many thanks

Markus

Comment 3

[Masatoshi Kimura [:emk]]

(In reply to Markus Wehr from comment #2)
> I believe i need to correct an issue with the mandatory Profile to fix this.

Oh, you are right. Firefox will not use the maintenance service if the update folder is created under the UNC path.
https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/updatehelper.cpp?rev=73ac7e81f316#644
https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp?rev=c4177c7f6f8b#2648

> In my case the update button Triggers UAC Prompt when it shouldnt.

If Firefox decided not to use the maintenance service, it will try to trigger the UAC prompt for standard users. but if the UAC GPO settings are configured to Automatically deny elevation requests, the attempt will fail.

Comment 4

[Markus Wehr]

Firefox 26 will not use Maintenance Service if Mandatory Profile is used:

- Install plain vanilla Win 7
- Copy Default Profile to c:\temp\cp.V2  (permissions=everone)   
- rename ntuser.dat to ntuser.man
- Create testuser with Profile Path= c:\temp\cp

Firefox will not use maintenance Service.

rename ntuser.man -> ntuser.dat

Firefox will use maintenance Service.

rename ntuser.dat -> ntuser.man again 

Firefox will not use maintenance Service.

Comment 5

[Markus Wehr]

Only "Standard users cannot update Firefox if Mandatory Profile is used"


Update works for standard users with    "HKLM...\Policies\System\ConsentPromptBehaviorUser"=0 (automatically deny elevation request)

It seems this value isnt used to calculate "isUnpromptedElevation" anyway.

In my case isUnpromptedElevation should return false.

Comment 6

[Masatoshi Kimura [:emk]]

You said update did *not* work with "automatically deny elevation request" in bug 711475. Which is correct?

Comment 7

[Markus Wehr]

It updates with "automatically deny elevation request". Courrent description is accurate. Its only the Profile Type Mandatory what prevents update.


(The Info was misleading. After all UAC has nothing to do with the issue. Without the GPO the behavior is exactly the same as reported from Jason.)

Comment 8

[Markus Wehr]

Profile Types that also prevent update:

TEMP Profile  
GUEST User Profile

It seems that Firefox checks the Profile Type - wheather changes will persist.

Comment 9

[Masatoshi Kimura [:emk]]

The cause of the failure was that CryptAcquireContext always failed with the temporary profile.
http://www.derkeiler.com/Newsgroups/microsoft.public.platformsdk.security/2003-12/0349.html
https://mxr.mozilla.org/mozilla-release/source/toolkit/mozapps/update/common/pathhash.cpp?rev=73ac7e81f316&mark=45-45,51-51#39

(In reply to Markus Wehr from comment #8)
> It seems that Firefox checks the Profile Type - wheather changes will
> persist.

We don't intentionally check the profile type, but it failed on temporary profiles as a result.

Comment 10

[Masatoshi Kimura [:emk]]

So we need to calculate MD5 without relying on Win32 Crypto to support Guest account or roaming profile.

Comment 11

[Markus Wehr]

it is possible to spoof the Profile type:

http://www.ivandemes.com/?p=305

i will see if it is possible in my environment without negative side effects.

Comment 12

[Masatoshi Kimura [:emk]]

As the page explains spoofing the profile will leave the to-be-removed profile data. Moreover an app shouldn't tamper the system status.

Comment 13

[Masatoshi Kimura [:emk]]

Attachment: Print more messages to update.log

It was nearly impossible to debug with the current useless log output.
Also, end users will just report "update.log is empty" without this change.
- Added a message for every exit reason.
- Added a message for each reason why the service was disabled.
- Don't wipe out the log if the update status is pending on restart.

Comment 14

[Masatoshi Kimura [:emk]]

Attachment: Make users using temporary profile possible to update using the maintenance service

CRYPT_VERIFYCONTEXT did the trick.

Comment 15

[Brian R. Bondy [:bbondy]]

Comment on attachment 8373970 [details] [diff] [review]
Print more messages to update.log

Review of attachment 8373970 [details] [diff] [review]:
-----------------------------------------------------------------

Robert could you take a look at this? I'm unsure about the log overwriting stuff.

Comment 16

[Robert Strong (they/them - no direct email)]

Comment on attachment 8373970 [details] [diff] [review]
Print more messages to update.log

emk, there are cases where these changes will cause writes to the update.log from both the elevated and unelevated updater. There are also tests that verify the contents of the update.log so has this been through try? I am leaning toward having at least some of these additional log messages written to a separate log so they don't get garbled when the elevated and unelevated updater write to the log. If you are in agreement let's do this in a new bug.

Comment 17

[Robert Strong (they/them - no direct email)]

Comment on attachment 8373970 [details] [diff] [review]
Print more messages to update.log

Cancelling review until answers are received for comment #16

Comment 18

[Masatoshi Kimura [:emk]]

OK, indeed this patch doesn't depend on the log stuff. I'll do it in another bug.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9201e3e02330

Comment 19

[Masatoshi Kimura [:emk]]

Filed bug 971224 for the log stuff.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9201e3e02330

Comment 21

[Masatoshi Kimura [:emk]]

Verified with the Guest account.
Fails: 2014-02-12 https://hg.mozilla.org/mozilla-central/rev/802d87c77e76
Works: 2014-02-13 https://hg.mozilla.org/mozilla-central/rev/a62bde1d6efe

Comment 22

[Masatoshi Kimura [:emk]]

Comment on attachment 8373971 [details] [diff] [review]
Make users using temporary profile possible to update using the maintenance service

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A
User impact if declined: Some users can't update the browser.
Testing completed (on m-c, etc.): Verified locally.
Risk to taking this patch (and alternatives if risky): Very low.
String or IDL/UUID changes made by this patch: None.

Comment 23

[Masatoshi Kimura [:emk]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8b17003640d4
https://hg.mozilla.org/releases/mozilla-beta/rev/b61023119a21

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/b61023119a21

Comment 25

[Masatoshi Kimura [:emk]]

Markus, could you verify this using yesterday's Nightly?
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-18-03-02-02-mozilla-central/firefox-30.0a1.en-US.win32.installer.exe

Comment 26

[Markus Wehr]

yes it updates with standard user account and mandatory Profile. (from 30.0a1 2014-02-18 to 30.0a1 2014-02-19)

So Firefox 28 will be the last Version i have push out manually?!

Comment 27

[Masatoshi Kimura [:emk]]

(In reply to Markus Wehr from comment #26)
> So Firefox 28 will be the last Version i have push out manually?!

Yes. Sorry for the inconvenience.

Comment 28

[Markus Wehr]

Thank you for the fix :)

Comment 29

[Bogdan Maris, Desktop QA]

I tried to setup my machines here in order to reproduce and verify this issue but with little success. 

Markus can you please verify that the issue is fixed on Firefox 28 beta 8 and latest Aurora?

For Beta 8 you can download an old Beta 7 build (eg: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/27.0b9-candidates/ )
For Aurora you can download an old Aurora build as well (eg: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/02/2014-02-01-00-40-03-mozilla-aurora/ )

Comment 30

[Masatoshi Kimura [:emk]]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #29)
> I tried to setup my machines here in order to reproduce and verify this
> issue but with little success. 

What does it mean? Will Firefox beta 28 not update on the Guest account? If so, it should be reported as a bug itself.

Comment 31

[Markus Wehr]

Bogdan,

please read Messages from Masatoshi Kimura above:

>> CRYPT_VERIFYCONTEXT did the trick.


https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-18-03-02-02-mozilla-central/firefox-30.0a1.en-US.win32.installer.exe

will update.
Oder Versions not using CRYPT_VERIFYCONTEXT flag will not use maintenance Service for Guest, Temp, Mandatory Windows Profiles.

regards
Markus

Comment 32

[Markus Wehr]

this worked: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/02/2014-02-28-00-40-00-mozilla-aurora/firefox-29.0a2.en-US.win32.installer.exe