Client: [Windows] privilege escalation for auto-update

[moscicki]

One of our Windows experts noticed, that currently owncloud client is unable to do privilege escalation for an auto-update. This means, that a user who already has administrator rights is required to log-in separately as an "administrator". A proper way of doing it would be to let the user who already has administrator rights to perform the update action (typically Windows would issue a confirmation dialog box that the process now runs with administrator privileges).

This is not an issue for enterprise updates by done an external tool/service.

[danimo]

Hmm, I do get a popup here when calling the installer with the same parameters as we do during updates...

[guruz]

Maybe related: https://github.com/owncloud/client/issues/2628#issuecomment-67998800

[moscicki]

Hello,

Any news on this? This is a problem on our infrastructure where users do not have access as "Administrator" but still they have administrator rights so they could perform this update.

Here are the details:

As mentioned before, the CERNBox sync client installation package for client asks for the password of the local administrator’s account. CERN users don’t normally have this password, because their CERN account have admin rights!
Unfortunately, using the CERN account does not work – probably because of a bug in its interaction with Windows User Account Control.

[michaelstingl]

@danimo @guruz When this will be fixed? Do you need more information? Could you recommend a workaround? /cc @MorrisJobke

00003267

[danimo]

@michaelstingl We' need to update the UAC component use for the NSIS Windows Installer, which implies changes in the NSIS installer script. I scheduled this for 2.0 originally, but let's see if we can do it faster.

There is no known workaround, but right clicking the installer an choosing "Launch as Administrator" might work.

[moscicki]

Thank you. Please note that we expect to use 1.8.2 for a longer time and we need to have "enterprise" and critical bug fixes in 1.8 line. A large installation like ours cannot jump from one version to the next in the development pace, especially for client-side tools.

[danimo]

@moscicki I know. This was way before your original report. I still have to find the duplicate issue.

[danimo]

Approaching this in the new_nsis_modules branch.

[danimo]

@moscicki I'd love to get some feedback on http://download.owncloud.com/desktop/daily/ownCloud-1.8.2.5138-nightly20150603-setup.exe (just on whether the installation now works).

[danimo]

Pull-request: https://github.com/owncloud/client/pull/3303

[danimo]

Seems to work according to https://github.com/owncloud/client/issues/3020#issuecomment-108387262, https://github.com/owncloud/client/issues/3020#issuecomment-108432317

[moscicki]

@danimo: do you expect this nightly to resolve the privilege escalation problem already?

[danimo]

@moscicki Yes. In fact any nightly from now on. I am still verifying it but we have 3rd party confirmation that this issue is fixed.

Correction: Use the next nightly build.

[Dianafg76]

@danimo I tested with Desktop v ownCloud-1.8.2.5153-nightly20150605-setup.exe, the problem is solved

[danimo]

@Dianafg76 Thanks but this is unfortunately not reliable as we figured. We'll have to push this to the next release.

[unclejamal3000]

Just FYI: I had this problem again with update to the 1.8.4 client (build 5267) on Windows 7 Prof.
I believe it had worked with the 1.8.2 version of the OC client.

[danimo]

@moscicki @unclejamal3000 Please try http://download.owncloud.com/desktop/daily/ownCloud-2.0.0.5345-nightly20150803-setup.exe. It should contain an installer that has the fix.

@Dianafg76 this needs to be tested by the reporter(s)

[phil-davis]

I tried that 2.0.0.5345 installer. I run it interactively and:

1. Windows correctly prompts me for priv and I say Yes.
2. Click "Next" to start through the installer dialog.
3. Leave the default "Uninstall before installing" checked. and click Next
   Unable to elevate dialog box appears:
   

If I select "Do not uninstall" and proceed through Next... the installer itself works fine and I have got the new version OK.
I am on Windows10
Edit add: All the same symptoms with 2.0.0-nightly 20150804 (build 5349)

[phil-davis]

Now I tried 2.0.0.5349 on my Windows10 Professional laptop that is in a domain.
It prompts for admin rights. I enter my administrator user name and password like I normally do. That is accepted fine. Then this dialog appears:

I haven't found any way to install in the domain. "Try again" just goes around the same loop.

[phil-davis]

These installer unable to elevate... are likely to all have the same root cause as the uninstall error issue just logged by @Dianafg76 https://github.com/owncloud/client/issues/3546

[danimo]

@phil-davis is your domain user a domain admin, or a local admin, or just a normal user?

[phil-davis]

I am running as a normal unpriv domain user, then the installer triggers the UAC screen/dialog and I enter the domain administrator username and password and try to follow the bouncing ball from there... Like I normally do with any utility software install on a domain client system.

[danimo]

@phil-davis cool, I think I can recreate this in our lab. thanks!

[phil-davis]

Note: I just tried the latest ownCloud-2.0.0.5351-nightly20150804-setup that just appeared and fixed https://github.com/owncloud/client/issues/3546 which was about another "Unable to elevate" error.
It did not fix the problem message "This installer requires admin access, try again" from a domain install.
I will try at home in 1 hour to see if it fixes the "Unable to elevate" error when running on a "normal" non-domain Windows system.

[phil-davis]

Tried at home on my Windows10 Home laptop that is not in a domain to install ownCloud-2.0.0.5351-nightly20150804-setup. That still has the ownCloud Uninstall "Unable to elevate, error:" problem described above.
So both issues still exist with this build. I was hoping that whatever helped #3546 would have helped something here :(

[danimo]

@phil-davis http://download.owncloud.com/desktop/daily/ownCloud-2.0.0.5351-nightly20150804-setup.exe works for me under the exact scenario (I am a domain user, and elevate to a domain admin for installation). I know the uninstaller of the previous version had errors. Maybe that's it? Try to not allow uninstall the previous version when installing the new one.

[phil-davis]

On the non-domain Windows10 system I uninstalled ownCloud client first. Then I installed 1.8.4 (so there would be something ordinary/know reasonable to uninstall). Then installed 2.0.0.5351, including Uninstall before install. That all worked fine. So that ownCloud Uninstall "Unable to elevate, error:" problem does seem to have been an issue with the uninstaller of the previous version.
Count that one fixed.

[phil-davis]

On the domain Windows10 system I uninstalled ownCloud client first to avoid any issue with uninstall - at least it uninstalled cleanly.
The problem on the domain system occurs directly after inputting the admin username and password at the UAC prompt. It comes up with "This installer requires admin access, try again" directly - there is not even the first ordinary dialog box of the installer.
I happen to have 4 different nightly build installers downloaded to that system:
2.0.0.5308 - install starts and runs fine
2.0.0.5317 - install starts and runs fine
2.0.0.5349 - has this "admin access" issue
2.0.0.5351 - has this "admin access" issue
I can see 2.0.0.5323, 5326 and 5345 online - I will download each of those and start the installer and report exactly where the different behavior started.

[phil-davis]

2.0.0.5308 - install starts and runs fine
2.0.0.5317 - install starts and runs fine
2.0.0.5323 - install starts and runs fine
2.0.0.5326 - has this "admin access" issue
2.0.0.5345 - has this "admin access" issue
2.0.0.5349 - has this "admin access" issue
2.0.0.5351 - has this "admin access" issue
Something happened between 5323 and 5326 - and not just a Microsoft "something happened".
Now to look at commits around that time 01 Aug 2015.- hmmm, there is new code about UAC_TryAgain and UAC_RunElevated. But without knowing all the ins and outs of client/cmake/modules/ NSIS.template.in I don't really see where there might be an issue.
I have a Windows7 desktop in the domain at work. I will try test on that tomorrow morning. At least then I know if it is something specific to a Windows version.

[phil-davis]

I tried with 2.0.0.5351 on a Windows7 desktop in the domain. That also gives the message "This installer requires admin access, try again" directly after I enter my admin credentials.
Then I tried logging in as my admin account and running the installer. In this scenario the UAC is just a Yes/No, no need to enter credentials. Still the same problem message "This installer requires admin access, try again".
The older versions listed above (2.0.0.5323 and earlier) install fine, so my admin account is good.

[jturcotte]

Ok, @guruz could reproduce it but it's difficult to figure might be going wrong without looking at the code. Looking at the output from Process Monitor, the child process is started with some /UAC: command line argument but it exits with a 1223 error code not so long after loading the UAC.dll installer plugin.

Some example of what could maybe go wrong: http://stackoverflow.com/questions/14141738/silent-install-with-win7-and-uac-plugin

[phil-davis]

2.0.0.5359 of 6 Aug 2015. I still cannot install on a domain system - I tried again on Windows10 and Windows7 and always get "This installer requires admin access, try again" after entering my admin credentials at the UAC prompt, or selecting "Yes" at the UAC prompt.

I tried on:
Windows Server 2008 R2
Windows Server 2012 R2
both domain controllers in this domain/forest.
They both install fine - I say "Yes" at the UAC prompt and the install proceeds fine.

So another data point - this is something to do with Windows domain client computers.

[phil-davis]

2.0.0.5361 installs fine on Windows 10 Professional in my domain. Good stuff, my issue is fixed.
I guess someone can review the detail of the original post by @moscicki and see if this is good to close.
Edit add: It works fine on 2.0.0beta1 for me.

[guruz]

@moscicki Any way for you to verify this too?
If not I think @phil-davis and my Windows VM are enough to close too..

[unclejamal3000]

Works for me with build 5376 on Win 7/8.1 (no domain).

[guruz]

Great!

[olahaye74]

Hi, I hit the problem with ownCloud client 2.1.0-5683 on windows 7 64bits (non admin account) when I want to upgrade from client interface.
A popup asks for admin account. I give .\local-admin with correct passwd and get:
Unable to elevate, error 5 (not 6)
The client has been installed with the local-admin account using right click, run as administrator (without running as Administrator, I hit the same problem. privilege dialog pops up asking for admin account and then I get the error 5 (not 6).

[MShekow]

ownCloud 2.5.1 installer shows the bogus "this installer requires admin access, please try again" message (after I fail to type in the "Administrator" password) on Windows 10 v1803, when "User Account Control settings" are set to "Never notify". Regression bug.

[michaelstingl]

@MShekow thank you very much for reporting this issue. With 2.5.x, the Win Installer got a full rewrite and is *.MSI based now. It would be very helpful if you could open a new issue with the relevant information, steps to reproduce etc.

[guruz]

@MShekow even better try 2.5.2-rc2 not 2.5.1 -> https://github.com/owncloud/client/releases/tag/v2.5.2-rc2

[MShekow]

Jesus, sorry, this bug actually affects Nextcloud's desktop client. Owncloud 2.5.1 setup works fine. I'll report the bug in the correct respository.