13

I have an 'auto-upgrade' mechanism that has been working for many years under Windows XP which fails under Windows 7 because the prompt to the User (which never existed under under Windows XP) to grant the program permission to run with administrator rights does not appear.

The win32 program (written in Borland Delphi) uses LogonUser() and ImpersonateLoggedOnUser() to impersonate a user (local account with administrator rights) so that it can replace selected files in the Program Files folder.

If I manually logon to Windows 7 using this user account and then attempt to delete a file in the Program Files folder Windows 7 prompts for my permission to allow the program to proceed - if I give it permission the file is deleted, if I deny permission 'access denied' is reported and the deletion is not allowed.

When attempting the same thing as described above 'access denied' is the result without any prompt to the user being given.

I see in a similar question herabouts (regarding the creation of temporary files (where the main thrust of the answers given is quite rightly 'don't do it') that such a prompt can be raised 'in code' but I cannot see where that method is actually explained.

S L Bentall
  • 257
  • 2
  • 11
  • +1 excellent question. Did you skip Vista? – Johan May 25 '11 at 22:37
  • Yes I did and although I've been running Windows 7 for a year it is only now that users of my software are preparing to migrate from Windows XP to Windows 7 so I cannot put off resolving the issue any longer. – S L Bentall May 26 '11 at 07:02

3 Answers3

5

You just need to mark your auto updater as requiring elevated privileges in your application manifest.

That said you might want to consider installing somewhere the user has write privileges.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Or make the bin directory on installation writeable by everyone on initial installation. I do this so that I can remotely upgrade unattended machines. – Misha May 25 '11 at 22:43
  • 6
    @misha It's naughty for installers to set ACLs on folders. Sysadmins will hate you! – David Heffernan May 25 '11 at 22:46
  • 1
    @Misha, remotely updating unattended machines is an administrative task, so it should be done by an administrator. You don't need to make a directory writable to *everyone* just so that it's writable to administrators. Making it writable to everyone means *anyone* can break the installation. Don't let unprivileged users affect other users' experiences. – Rob Kennedy May 25 '11 at 22:59
  • @Misha, you're fired. :) This is the worst possible thing you can do, as it exposes the bin folder to access by viruses and malware even when the new security (running as a non-administrator) is in place. Shame on you. – Ken White May 25 '11 at 23:44
  • No, only the directory that the files are installed under. This does not affect any other installation on the machine, and is akin to installing under somehing like C:\. The alternative is to just install the application elsewhere, so there is really no difference. – Misha May 26 '11 at 00:43
  • @Rob, when running on a kiosk you automatically login the user, who is not likely to be an adinistrator. This technique allows you to update the machine without logging off the default kiosk user. – Misha May 26 '11 at 00:49
  • Just to be clear, the only directory that has changed permissions is the C:\Program Files\ folder. So, this does NOT affect anyone else's installation. This is the same premise as installing outside the C:\Program File directory. If this is not done then you CANNOT update the installation from the application that is running, OR it needs user intervention to up the priviledges. So, you can talk about theory all you like, but in practice this works well and is less complicated than having multiple applications do the update or requiring user intervention (not possible in a kiosk). – Misha May 26 '11 at 01:02
  • 1
    @misha best then to install outside program files – David Heffernan May 26 '11 at 05:56
  • @David, yes, that is often what is done. For most situations there is the perfect solution, and then there is the solution that the client will pay for, and believe me, no client ever wants to pay for the perfect solution ;-) – Misha May 26 '11 at 13:39
3

You partly seem to be asking how to run code elevated. There are a couple of answers to the question below which provide links to the information you need to invoke functionality running elevated:

Delphi: Prompt for UAC elevation when needed

Community
  • 1
  • 1
Conor Boyd
  • 1,024
  • 7
  • 15
0

Well two years have passed, my clients are at last adopting Windows 7 and I have finally got round to circumventing the problem I was trying to solve (temporarily gaing sufficient rights to replace executables in Program Files under Windows 7) by replacing my own installer with an Inno Setup installer (incorporating additionl logic carried over from my installer using Pascal Scripting). Inno Set handles all the permissions issues - hurrah.

S L Bentall
  • 257
  • 2
  • 11