My installer installs the app to "Program files\MyApp", the app when running changes files within this location. On Vista, by default this brings up UAC issues.
I want users to be able to run MyApp without being admisn or fighting the UAC screen everytime they run the app. If they have to get through UAC to install the app, that's OK though still not optimal.
I thought I had this set up, but it's not working:
[Setup]
PrivilegesRequired=admin
AppName=My App
AppVerName=My App 1.0
DefaultDirName={pf}\MyApp
DefaultGroupName=MyApp
UninstallDisplayIcon={app}\bin\MyApp.ico
OutputDir=..\Installer
ChangesAssociations=yes
[Dirs]
Name: "{app}\"; Permissions: everyone-modify
Name: "{app}\redist"; Flags: deleteafterinstall;
Specifically I thought Name: "{app}\"; Permissions: everyone-modify would let normal users run it, removing UAC protection on Program Files\MyApp.
I am picking at values a bit by random, can anyone suggest some changes? Again, the aim is that once installed, normal users in non-admin accounts can run it even though files are saved in Program Files, without UAC kicking in. As a secondary thing, the installation itself should not be too crazy... a single prompt for admin password or UAC authorization.
Don't install under {pf}. Instead, install to a user-writeable location (for instance, {localappdata}).
http://www.kinook.com/blog/?p=53
You should change your app so that is saves shared data in some other folder.
Granting write permissions for any user to a folder in PF that contains executable code (exe,dll's etc) is a security issue (Evil user could modify exe file and wait for admin to run it)
Alernativly you could store the files in a subfolder in PF and only grant write access to it, that way your executables are safe.
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
I have a Delphi 6 program that for most users installs fine while running under a user account without admin privileges. However, on some systems it triggers a request for admin rights. Unfortunately mine isn't one of them so it's hard for me to diagnose this problem. I use InnoSetup 5.1.9 to build my install programs.
How can I figure out what I need to change about my installation program's configuration to neutralize the need for admin rights on some people's systems? It's causing trouble for my system because during installation, certain program data files are being copied into the admin account's application data folder. Then when my program is launched under a user account, those files can not be found since they are not in the user account application folder, where they are expected to be.
This happens due to default PrivilegesRequired directive value, which is, by default configured to require administrator elevation. If you don't need this, simply change in your InnoSetup script, value of this directive explicitly to something like this:
[Script]
PrivilegesRequired=lowest
From the reference:
When PrivilegesRequired is set to lowest, Setup will not request to be
run administrative privileges even if it was started by a member of
the Administrators group. Additionally, the uninstall info root key
will always be HKEY_CURRENT_USER, and the "common" forms of the Shell
Folder constants are mapped to the "user" forms, even if
administrative privileges are available.
I made a small application and installation package for the application with installshield LE designed for Windows Xp/Windows7 32bit.
Everything is working ok but i have premission issues.
First of all, if user is not administrator then he cant install the installation package.
(In the Require administrative privileges i entered "No") - This issue is OS or installation package restriction ?
So.. I went to XP and logged in as normal user, i launched the installation and it elevated me to be admin. then I entered an admin password in order to continue the installation. afterwards everything went fine. now i cant start the application - only as administrator.
Why is that? how can i do that the user can run the application ?
it cant write the logs file (which my application writes) to the program files folder.. no premissions..
How can i handle this ? If a certain user installed the application i want him to be able to do anything with it. only the installation itself require admin log in.
Thanks
The Program Files folder is a very special directory. Only admins are supposed to make changes to that. If your installation writes logs to Program Files, it is just wrong.
If you need a normal user to install and interact with your application, you should create an application and an installer suited for STANDARD USER. Such an installer will not write anything into Program Files.
Have a look at this:
http://blogs.msdn.com/b/rflaming/archive/2006/09/30/778690.aspx
If I install my app to program files, will it always be able to create and write files within its install directory? It seems to work in a lot of different versions of windows, but are there situations where this wouldn't work?
Mainly I'm using this approach for logging. If this is not the correct approach, is there a better place to log?
Note: My installer requires Admin privileges to run and it grants Full Access to all users in the install directory.
Apps don't run as users, users run as users. If you install an app into Program Files, and let's assume you needed elevated permissions to do so, when your standard user then runs that app, that is the user that needs permissions.
App is installed with elevated permissions (user: Admin, for example)
All permissions on the AppName folder might well be "Admin:Full, Users:Read"
User runs app, so cannot change any files
At install-time, your installer will need to know which of it's own files need to be made writable to standard users, and set permissions accordingly. Of course, user-data should not be in Program Files anyway. That's what %appdata% and the user profile are for, usually.
If your app has a globalsettings.ini or whatever, that lives in "Program Files\YourApp", then while you have admin permissions (i.e. at install time) you need to grant write permission to all users to that globalsettings.ini file. Or Power Users. Or a group. Or whatever is correct for your app.
In summary, no, users do not have default write-access to ProgFiles, nor should they.
Yes, there are definitely situations where this won't work, such as when your app is running on Windows 7, or if your user account is a limited user.
We always put our log files in a temp directory or a special folder such as AppData.
I'm currently working on my applications installer and I'm wondering where the executable files should be installed to in Windows 7.
If I'm installing as admin my executables files get put in C:\Program Files.
If I install my product as a normal user where should the executables be put?
Thanks in advance.
Which installer are you using?
MSI runs in elevated privileges. You can install your application in program files folder
Put the files in the user folder.
This will mean that the application is only available to that user.
You should probably store that in the AppData directry, as I saw you mention in reply to #ChrisF. Remember that the user can move this directory though, so I wouldn't point to it explicitly. There is an environment variable that you can grab, that only applies to the logged-in user, which is %AppData%.
Keep in mind that putting it in %AppData%/Roaming would follow the user across multiple machines on the same Domain and %AppData%/Local would just stay on the one machine.
The executables should be under Program Files, who's precise location may vary from installation to installation. This means that the setup should run elevated. If InnoSetup makes .msi files, they will request elevation. If it makes a file called setup.exe, it will also request elevation. If for some reason the exe has a different name, like GetStarted.exe, then you should hand create an external manifest (GetStarted.exe.manifest) and put in requireAdministrator for the requestedExecutionLevel which will ensure your installer requests elevation.
Regardless of how it requests elevation, if the user doing the install is an admin (eg you) they will just have to click consent. If they are not an admin they will need to get an admin to consent for them. After that the installer will be able to write to Program Files.
If it's important to you that non admins be able to install the app then have the executables go under the users profile - but that would not be my first choice. The protection given to Program Files means that users are less likely to find themselves with messed up copies of your application if you install it to the protected area.