Installation issue on win7 with standard user and UAC off

Archive: Installation issue on win7 with standard user and UAC off

air_circle
18th July 2012 08:10 UTC

Installation issue on win7 with standard user and UAC off
Hello, dear friends

We have one XP application, Now need to support win7(for all users: admin, standard)
I meet some issues in standard user with UAC off:
1. Can not create new sub registry in ${HKEY_LOCAL_MACHINE} SOFTWARE, and can not write any registry value.Code example:
!insertmacro CreateRegKey ${HKEY_LOCAL_MACHINE} SOFTWARE\MyApp
WriteRegStr HKEY_LOCAL_MACHINE SOFTWARE\MyApp Version 1.14.83
2. Can not create the uninstall shortcut in the add/remove control panel
User need to install the APP in standard user level.

Anyone know how to fix it? Hope someone can help me! Thanks!

Afrow UK
18th July 2012 10:50 UTC

You cannot write to HKLM as a limited user. If your application does this also then it must be modified to write to HKCU instead.

Edit: You can also create the Add/Remove registry under HKCU.

Stu

Anders
18th July 2012 21:05 UTC

The exact same issue exists on XP (and every version of NT before that), you just forgot to test as non-admin on XP...

air_circle
19th July 2012 03:16 UTC

Our APP need to do a per-machine installation. The request is that one user install it in the same pc, other users shall be able use it.
If write to HKCU instead, then comes one issue:
After user A install the APP, the user B can see the APP, but will not be able use the APP since the registry value is not available for B.

And Our APP works well on XP, since user will always have admin permission on XP and we don't want to re-implement the APP.

So, NSIS can not finish the per-machine installation on standard user level?

MSG
19th July 2012 06:11 UTC

Originally posted by air_circle
And Our APP works well on XP, since user will always have admin permission on XP and we don't want to re-implement the APP.

Users on XP are not always admins. New users may be admin by default, but that's not a reason to assume that nobody ever creates a userlevel user. Any smart system administrator would make his company's pcs use userlevel users, not admins.

Originally posted by air_circle
So, NSIS can not finish the per-machine installation on standard user level?

It's not that NSIS cannot do it - It's that Windows will not allow it. If you want to do something for all users, you MUST have administrative access. Once you're admin there are many ways to accomplish what you want to do, but it involves either making some ugly hacks OR fixing your application to follow Microsoft Windows standards. If you want some location where your application can write data for all users, you need to use alluser Appdata. That's what it was designed for.

More hack-job solutions (please don't do this):
- Create a service that automatically runs at admin level to handle all the admin-level tasks your app needs. This solution is used for example by the Steam client, because it must be able to install games which sometimes (but not always) requires admin.
- Enumerate all userhives in HKU and create reg info for each user, plus the default user hive.
- Make your HKLM regkey world-writable.

air_circle
19th July 2012 08:08 UTC

MSG,

Thanks for your detailed info.

Do you know any info about following?
1.What's the alluser Appdata folder on win7? is it %public%?
2.Do you know any alluser registry location with write/read permission?

Thanks

Afrow UK
19th July 2012 10:54 UTC

If you are doing an all users install then you must install with administrator privileges. You can then write to HKLM, $PROGRAMFILES and you can write shortcuts for all users (SetShellVarContext all).

Add RequestExecutionLevel admin to your script and then in .onInit check the user has administrator privileges using UserInfo::GetAccountType.

Stu

MSG
19th July 2012 17:04 UTC

Originally posted by air_circle
1.What's the alluser Appdata folder on win7? is it %public%?
2.Do you know any alluser registry location with write/read permission?

1. It's %APPDATA% after you do setshellvarcontext all
2. World-writable alluser registry does not exist as far as I know.

Anders
20th July 2012 07:15 UTC

Originally posted by air_circle
1.What's the alluser Appdata folder on win7? is it %public%?

No, public is for documents etc. CommonAppdata=Programdata on NT6.

See also:
http://blogs.msdn.com/b/oldnewthing/.../10327322.aspx
http://blogs.msdn.com/b/aaron_margos...i-do-that.aspx

air_circle
23rd July 2012 11:39 UTC

But Programdata folder is limited access for such cas:
usera:admin
userb:stand
In the same pc, if usera create the common user data file, then the userb will have no pemission to write.How to handle this case?

Can install app into c:\users\public?
I just found all users(admin/standard) have permission to write/create new file/folder in this folder.

MSG
23rd July 2012 15:00 UTC

If I understand Anders's links correctly, %PUBLIC% is simply the new allusers startmenu/desktop/etc. These folders were not world-writable in WinXP, so I would guess they are also not world-writable on Vista/7.
In contrast, Program Data is the new allusers Application Data. This folder IS world-writable in XP/etc. Therefore I would expect it to be world-writable in Vista/7 as well.

I don't have a Vista/7 virtual machine at hand right now, so I can't test the above assumptions. But I do remember testing it in the past without trouble. Are you sure you cannot write to your programdata folder as user?

air_circle
25th July 2012 07:27 UTC

Yes, I do some test on my win7.

First, log in with admin, and launch my app, then it create the common configure file configure.ini in the Program Data\myapp.

Second, log in with standard user, launch my app, it can not change the configuration file configure.ini, there is no write permission since the file is created by amin.

Third, i tried to install the app into %public%, i repeat the step 1 and step 2, it is passed, all user can add new configuration in the configure.ini file.

On win7, the %public% is c:\users\public, this is new folder from vista, there is no this folder on XP.

From my test result, I plan to install the new app into %public% on win7, but on XP, will keep installing the app into C:\Program Files.