During my innosetup application installation, I am registering a dll (which is used for windows right click context menu and icon overlays, something similar to dropbox/tortoise cvs) and performing some other stuffs also. Till now, I am insalling the application only for the administrator user. The dll will write the information in HKCR, HKLM. Now, I plan to support installation for other non-admin users too (standard user).
I tried several things like below,
changed the privilegerequired from Admin to none.
changed all registry updates from HKLM to HKCU.
But, if I try to install the application, the dll registration failed due to unable to write on HKCR. So, I planned to register dll only for the admin user. And for other normal users, plan to skip the dll registration and do the other stuff. But I can't find out, how to identify the current users is a admin user. Can any one let me know the following things,
can we identify whether the current login user is a admin/power user or not?
can we register dll (writing HKCR) with out admin rights?
Thanks for your reply.
You can check whether the current user is admin or power user:
[Code]
function IsRegularUser(): Boolean;
begin
Result := not (IsAdminLoggedOn or IsPowerUserLoggedOn);
end;
If you are installing things to HKLM, then you are already installing for all users, not just the administrator user. So you shouldn't change that.
The correct thing to do in an installer is to never write to HKCU. (For best results, also never write to HKCR -- write to HKLM\Software\Classes instead.)
Related
A very common question about creating (Inno Setup) installers revolves around accessing/modifying a profile of a specific user (the currently logged in user) from an installer that runs with elevated/Administrator privileges.
Doing this has many drawbacks and is error prone.
All the existing answers cover part of the problem (registry, files, desktop icon, etc). A purpose of this question is to collect answers that address the problem globally, with all possible approaches.
Inno Setup does not have any built-in mechanism to access or modify user environment from installer running with elevated/Administrator privileges.
All the attempts to achieve this rely on tricks like:
runasoriginaluser flag or ExecAsOriginalUser function. Some examples:
Modifying or accessing registry of logged in user:
Inno Setup Creating registry key for logged in user (not admin user) or
How to read registry HKCU for logged In user from Inno Setup installer running as administrator
Accessing AppData folder of logged in user:
Inno Setup always installs into admin's AppData directory or
Inno Setup Using {localappdata} for logged in user or
Inno Setup - puts user files in admin documents.
or using {user*} constants.
Though these are not reliable, at least for these reasons:
When the current user does not have Administrator privileges, (s)he needs to enter Administrator credentials on installer UAC prompt. That switches the installer to a different user. So {user*} constants will not refer to the user that initiated the installation.
When the user explicitly runs the installer with elevated privileges, e.g. by right-clicking the installer and selecting "Run as administrator" or running it from another elevated application (file manager), the "original user" for runasoriginaluser flag or ExecAsOriginalUser function will already be elevated.
In corporate environments, applications are installed by Administrator, who is not the user that will be using the application.
The only correct generic solution to this problem is to defer a setup of the user environment only to the actual user session.
Easiest is to have the application itself do the setup on its first run.
The installer can only deploy shared files that the application can use for the setup.
If you cannot modify the application for whatever reason, you would have to iterate all accounts and modify them:
for files: Inno Setup Create individual shortcuts on all desktops of all users
for registry: Uninstall auto-run registry entries for all users
If you need to make sure the settings get distributed to accounts that get created only after installation, see How to install files for each user, including future new users, in Inno Setup?
If you are happy with a fact that the application will be setup for the logged in user only, use PrivilegesRequired=lowest:
[Setup]
PrivilegesRequired=lowest
Then the {user*} constants will correctly refer to the current user's folder.
If you still need Administrator privileges for some sub-task of the installation, you can requests privileges elevation for the sub-task only:
Inno Setup - Register components as an administrator
Inno Setup - Access unprivileged account folders from installer that requires privileges
If you want to prevent user from breaking this by explicitly running the installer with Administrator privileges, see
Can't get Inno Setup postinstall Run item to runasoriginaluser or
my answer to How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.
Or you can programmatically find out, what is the account of the current Windows logon session:
Determine if Administrator account that runs elevated Inno Setup installer is the same as the account of the current Windows logon session.
Another option is to allow the installer to install for the current user only:
Make Inno Setup installer request privileges elevation only when needed
A very common question about creating (Inno Setup) installers revolves around accessing/modifying a profile of a specific user (the currently logged in user) from an installer that runs with elevated/Administrator privileges.
Doing this has many drawbacks and is error prone.
All the existing answers cover part of the problem (registry, files, desktop icon, etc). A purpose of this question is to collect answers that address the problem globally, with all possible approaches.
Inno Setup does not have any built-in mechanism to access or modify user environment from installer running with elevated/Administrator privileges.
All the attempts to achieve this rely on tricks like:
runasoriginaluser flag or ExecAsOriginalUser function. Some examples:
Modifying or accessing registry of logged in user:
Inno Setup Creating registry key for logged in user (not admin user) or
How to read registry HKCU for logged In user from Inno Setup installer running as administrator
Accessing AppData folder of logged in user:
Inno Setup always installs into admin's AppData directory or
Inno Setup Using {localappdata} for logged in user or
Inno Setup - puts user files in admin documents.
or using {user*} constants.
Though these are not reliable, at least for these reasons:
When the current user does not have Administrator privileges, (s)he needs to enter Administrator credentials on installer UAC prompt. That switches the installer to a different user. So {user*} constants will not refer to the user that initiated the installation.
When the user explicitly runs the installer with elevated privileges, e.g. by right-clicking the installer and selecting "Run as administrator" or running it from another elevated application (file manager), the "original user" for runasoriginaluser flag or ExecAsOriginalUser function will already be elevated.
In corporate environments, applications are installed by Administrator, who is not the user that will be using the application.
The only correct generic solution to this problem is to defer a setup of the user environment only to the actual user session.
Easiest is to have the application itself do the setup on its first run.
The installer can only deploy shared files that the application can use for the setup.
If you cannot modify the application for whatever reason, you would have to iterate all accounts and modify them:
for files: Inno Setup Create individual shortcuts on all desktops of all users
for registry: Uninstall auto-run registry entries for all users
If you need to make sure the settings get distributed to accounts that get created only after installation, see How to install files for each user, including future new users, in Inno Setup?
If you are happy with a fact that the application will be setup for the logged in user only, use PrivilegesRequired=lowest:
[Setup]
PrivilegesRequired=lowest
Then the {user*} constants will correctly refer to the current user's folder.
If you still need Administrator privileges for some sub-task of the installation, you can requests privileges elevation for the sub-task only:
Inno Setup - Register components as an administrator
Inno Setup - Access unprivileged account folders from installer that requires privileges
If you want to prevent user from breaking this by explicitly running the installer with Administrator privileges, see
Can't get Inno Setup postinstall Run item to runasoriginaluser or
my answer to How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.
Or you can programmatically find out, what is the account of the current Windows logon session:
Determine if Administrator account that runs elevated Inno Setup installer is the same as the account of the current Windows logon session.
Another option is to allow the installer to install for the current user only:
Make Inno Setup installer request privileges elevation only when needed
I've just developed a .NET program which has the ability to patch itself.
I've noticed that the patching process only runs if I choose "run as administrator".
It seems I need to "create and embedd an Application Manifest", according this this:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
So my question:
Is it normal for applications like mine (which can patch themselves) to require Admin rights, and is this the route I should be going?
Thanks
If your application does not normally require elevation then I don't recommend that you request it in your manifest because it will be very annoying for your users. Firefox uses a NT service to get around the UAC dialog but I can't really recommend that either unless your updates are very frequent.
I would suggest that you write a little updater application that does the patching. It can request elevation in its manifest and this way the user only has to elevate when there is something to patch. If you don't want another .exe in your bundle, you can execute yourself again with the runas verb when you need to patch.
Edited the NSIS script to include this line:
AccessControl::GrantOnFile \"$INSTDIR" "(S-1-5-32-545)" "FullAccess"
This gave the User account full access to the application folder within Program Files, meaning my patcher could write to it without any problems.
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?
I am having a huge problem with the eventlog on my server. Right let me first of all explain the setup.
I have a domain setup with 2 computers
One computer is running IIS the other is a workstation. The IIS is running Win2k3 the workstation Win XP.
The IIS computer is hosting a website which uses Windows Impersonation and tries to log an entry to the eventlog for a custom log file called MyApp and a custom event source MySource
I have a domain user called MyUser who is just a member of Domain Users.
Single Sign On is working 100% because I can write out the logged in user to the page fine.
When I visit the IIS page from the workstation I get one of the following messages (sometimes I get the first sometimes the second)
1) The handle is invalid
2) Cannot open log for source 'MySource'. You may not have write access.
So to try and fix this I have tried all of the following:
Granted the Everyone user FullControl to C:\windows\system32\config\MyApp.evt file
Granted the everyone user FullControl to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog
In the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\MyApp\CustomSD I appended the following string (A;;0x0002;;;AU), (the reason for this can be read here http://fgheysels.blogspot.com/2008/01/cannot-open-log-for-source-0-on-windows.html)
I am now totally out of ideas of how to fix this. Has anyone else come across this and have you tried anything else.
The error, as you seem to have found already, relates to writing to event sources or creating them. I would suggest you try the following.
You did not indicate if the event source exists in the registry or weather the .evt files ware created by the system or if you put them on the machine, so it is hard to determine at which point you are stuck.
You also did not mention if this works on some developer's machine, in which case you can compare the registries and even create the keys manually if you have to.
Have a look under ...\Eventlog if a key for your log has been created (MyApp?).
Have a look in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\MyApp.
There should be a key called Sources. Does your source appear in here?
If these entries do not exist the error is that your user does not have permissions to create the custom log and source.
In the error message it should indicate a ThreadIdentity parameter, which should indicate which user account it is attempting to use to do this. You can also open the permissions to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog and query the "Effective Permissions" for this particular user to ensure it effectively really has full control.
Try granting full control to the entire directory C:\windows\system32\config\ and not just the .evt file as the system needs to create some additional files here as well.
Lastly you can try and enable anonymous access to the website and run it as the machine/Domain administrator user once so all the keys get created before setting it back to the way you like it. You could also try enabling impersonation in the web.config file to ensure that it is not running without a windows identity. These ones you should all be able to undo once the correct keys and files have been created.
Let us know what you find after this and we can take it further.
Well after many hrs of trying to solve this I appear to have a solution which works.
First of all I had to allow the Authenticated Users group write access to the event log. I advice you backup your registry before continuing.
Run regedit
Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
Open the subkey which matches the EventLog you are writing to (so I will pick Application)
On the right you will see the registry strings, locate one called CustomSD
Right click and modify it.
Append to the end (A;;0x2;;;AU) (I will explain this later)
Save the changes (I don't know if you need to reboot or not)
So that will mean Authenticated Users can write to the Application event log. I needed to apply one more change.
Open the Domain GPO or local computer GPO
Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights > Assignments > Manage auditing and security log
Go to its Properties window
Select Define these policy settings
Add the Administrator group
Add the Authenticated Users group
Save and do a gpupdate /force for the affected computer.
That is the only way I could get it to allow my website users to write to the event log.
I mentioned in part 1 step 6 I would explain the string we added. Please see this page for more details http://support.microsoft.com/kb/323076