I have a installer created in visual studio 2010 which writes into HKCU of registry. It requires administrative privilege during both installation and running.
Now when I am installing it with administrative privilege, from a standard account the registry entries are written into standard user's HKCU registry part. But when I am running it with administrative privilege,it is reading from administrator's registry HKCU.
After lot of searching I came to the conclusion that when you run a program with elevated privilege, It searches for the elevated user's HKCU. But why same thing is not happening during Installation as I have administrative privilege at that time also.
According to another stack overflow question, opposite thing is happening, i.e. Elevated installation writes to admin's HKCU. Can anyone help me how to achieve that workaround.
[Note: I am aware that changing the code to read and write from HKLM ,rather than using HKCU may be best solution for this ,but not for me .Because recently it was changed from HKLM for another big issue and cannot be reverted.]
Now when I am installing it with administrative privilege,
How do you actually start the installation? Do you have an EXE wrapper over your MSI and launch it with the command "Run as administrator"? Is that wrapper launching the MSI latter on during the installation?
Normally, if an MSI is launched by an elevated process (be it the EXE wrapper or a an elevated cmd.exe) the per-user data (registry and files) are redirected to the locations of the new user (i.e. the admin under which now the installer is running). So your registry entries should be created also under the administrator's HKCU hive and your application should find them when launched as an admin.
As a side discussion, is not really recommended to have an application load entries from HKCU but run it directly elevated, things can get confusing. If you want your app to run as admin, then you should install it per-machine and use the appropriate file and registry locations. What was the bug that made you guys switch to per-user installation? (maybe we can help with a better solution)
Related
I have created a win32 application in Visual Studio 2010. the application is sort of installer, it copies an exe to system32 folder.
The exe which is copied by installer is executed every time the windows is restarted. i have created an entry for it in the registry, now the problem i am having is i want to run that exe as administrator every time it is executed.
I can change the properties of the exe to run as administrator, but it works only for the specific system, i have mentioned my application is an installer, so it is quite hectic to change the privileges at every system.
Kindly guide me how can i solve this problem
First of all, please note that privileges and rights are specified for users rather than executables.
In order to have an executable run elevated, you typically need to add an application manifest to your executable that specifies the requireAdministrator execution level. Such an application will fail to run if the user is not an administrator, or cannot find an administrator to perform over-the-shoulder elevation.
Now, this probably won't help you much. If you want elevation to happen at logon (assuming your registry setting is HKLM\Software\Microsoft\Windows\CurrentVersion\Run) then this will lead to the user being presented with a UAC elevation dialog every time the program starts. I cannot imagine that behaviour is desirable.
Perhaps the cleanest way to avoid all of this would be to convert your application to run as a service. Services run in session 0 and are not subject to UAC. Simply run the service under a user account that has sufficient rights.
One final point, that I cannot stress enough. You should not be copying files to system32. That is the system folder and it belongs to the system.
My installer requires admin privileges. During installation some values are written to the HKCU tree of the registry of the currently logged on user. However, when this user account is a so called standard account, the user has to specify credentials for an administrator account when the installer starts. The values are then written to the HKCU tree pertaining to this admin account instead of the HKCU of the currently logged on user.
The same problem arises when the installer wants to write some data to the local AppData and wants to create a shortcut on the desktop.
How do I circumvent this?
This happens because you are using a per-machine installation which writes data in a per-user location (HKEY_CURRENT_USER).
The correct approach is to use either a per-user installation with only per-user locations or a per-machine installation with only per-machine locations (HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER).
If you are asking for admin rights it normally means you are doing a system-wide/machine install for all users. When creating this type of installer it is not a good idea to write to HKCU or %USERPROFILE%, not just because you can end up performing actions for "the wrong user" but you also end up initializing the install for just that one user and not all users.
What I recommend is that you write this common data to HKLM\Software\YourCompany\YourApp\CommonData and/or <CSIDL_COMMON_APPDATA|CSIDL_PROGRAM_FILES>\YourCompany\YourApp\CommonData and then import this data in your application the first time a user run's it.
You might also want to consider creating a per-user installer (like Chrome) but this means you can only write to HKCU and %USERPROFILE%!
My application updates some registry fields related to licensing under HKLM. This is for accessing the information for all users in the system. This makes us to make our application run as administrator. Is there any other location in registry where I can keep information which can be accessed by all users?
Registry HKLM and folder %ALLUSERSPROFILE% are accessible to all users, but meant for writing to at install time (as admin).
Registry HKCU and folder %APPDATA% are accessible to current user and meant for writing to at any time.
Why are you modifying licensing info (shared by all users) during run and not just during install?
You could place as an (e.g.) XML document in the file system under a shared folder instead of the Registry.
E.g. System.Environment.SpecialFolder.CommonDocuments or CommonApplicationData.
No there is not. If you have to make a modification that will affect/be visible to all users, you have to deal with UAC or elevate your application on startup. This is part of the design of UAC. If, however, you were to write to a file you could grant all users access to that file without UAC interference.
If, however, you are only reading the registry, you can do this without elevating your security rights. Therefore, if you write once to the registry and then just read it later, you can do so when only elevating your privileges once.
Here is an article on playing nice with UAC:
http://msdn.microsoft.com/en-us/magazine/cc163486.aspx
I'd make your installer precreate the registry entries (it runs as admin typically), and open up their permissions using GetSecurityInfo and SetSecurityInfo. Then your app can write to them without any special perms.
Goal:
It sounds a little bit odd, but I have to prevent that a software starts with administrative rights.
Problem:
I have a setup tool that installs the software very well. After completion the setup starts the software itself. Because the setup tool runs with administrative rights, the software that will be startet automatically after the setup does the same.
But all Settings that the program need, won't be written/read correctly that time, because due to the UAC virtualization, the config directory is different to the config directory the user would have without administrative rights.
Question:
Is there any way to downgrade from admnistrative rights to user rights, if the parent process owns administrative rights. App.config? StartParameter? or something else
Info: I'm using the INNOSETUP to build the setup tool.
Thx for your help
Just set runasoriginaluser flag for running application.
Yes, you can start a process non-elevated, however I'm not sure how this integrates with InnoSetup. The instructions are How do I start a program as the desktop user from an elevated app.
Consider marking your application with appropriate manifest to suppress UAC virtualization, it will then use the same directories in both cases: non-elevated and elevated. And better use directories in user's profile without relying on virtualization.
I'm working on an installer for our application. The installer makes some changes to the HKEY_CURRENT_USER\Software\Company\AppName registry key, which the application then looks for the first time it runs. The application then does different things based on the registry keys it finds.
This works great, until you try to install the application as a user account (i.e. non-administrator) on windows 7 (and maybe Vista, I haven't tested that yet).
When the user tries to install the application, Windows elevates to the administrator account's credentials. This means that any changes to HKCU in the registry are made to the administrator's registry, not the launching user's registry. Thus, the keys are not visible to the application when it launches for the first time under the user's account.
We can't be the only people whose installer needs to communicate with the app it installs. Is there no way to reliably use the registry to do this?
We can't rely on the user launching the app after he installs it, so passing the information as a command-line parameter isn't a viable solution. The only way I can see to do it is to have the installer invoke a utility as the original user, which gets or sets the registry key itself; this seems to be a bit of a silly hoop to have to jump through.
Edit: The application needs to delete the keys after it's used them, so I can't just put them in HKEY_LOCAL_MACHINE.
There are 2 recommended approaches for what you want:
Use a per-user installation which
doesn't require Administrator
privileges. You will be able to use
HKEY_CURRENT_USER, but your product
is not installed for all users.
Use a per-machine installation which requires Administrator privileges. In this case you need to redesign your application so it reads its settings from a configuration file. HKEY_CURRENT_USER should be used only when saving user-specific settings, not for global application settings.
Basically, if your application is per-machine, it should use HKEY_LOCAL_MACHINE or a configuration file. If it's per-user, you can use HKEY_CURRENT_USER. Any other combination has limitations and will not work the way you need.
If you need your application's information to be available to all users, use the HKEY_LOCAL_MACHINE hive.
EDIT - 2 alternatives:
Change the security of your registry
keys to allow users to edit/delete
them,
Use the ProgramData directory (instead of the registry) to store
the data.