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
Related
My installer run in all users, and it saves user information in the AppData folder.
The problem is that, when the installation is finished, an executable is launched by means of an Exec and it is launched as the administrator user, so all the session data is stored in the administrator's AppData. I want to run the installation as Admin but the last step as the current user.
RequestExecutionLevel admin
Can I launch my application as the current user? Can I keep the current user before ask for admin privilages?
The Microsoft guidelines say:
Certification requirements for Windows Desktop Apps
Apps must install to the correct folders by default
10.6 Your app must write user data at first run and not during the installation in per-machine installations. When the app is installed, there is no correct user location in which to store data.
If you have some sort of default user data/template you should install that in %ProgramFiles% or %ProgramData% and your application should copy that data to %AppData% the first time a user runs your application.
The ShellExecAsUser and StdUtils plug-ins can be used to execute your application as the "real" user on the finish page.
The UAC plug-in allows you to access the "real" users %AppData% and registry but I don't recommend this approach because the plug-in is hard to use and it really promotes incorrect behavior. You are very likely to end up with a install pattern that only works for the initial user and not other users on the same machine.
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
I have created a Word Add-In setup.exe file with installshield and I'm trying to find out how to install it without needing administrative privileges. Furthermore, I need the installation to be silent(No UI). I was able to get that to work by extracting the msi file from the executable and run it using
msiexec /i setup.exe /passive
This works perfectly on my machine, but it won't work for any other user in the client's system. The client uses a different system, so when I try the same command, I see that the files are added to my program files, but it isn't in my list of installed programs and the registry keys aren't set. I am not able to make any changes to their system, so I'm trying to find a way to bypass this whether it be third party programs or a little cheat I can use in the command prompt.
I have attempted the following:
Turning off UAC prior to running the command above.
I have removed the node from the manifest file.
numerous commands in the command prompt.
Does anybody else have any other suggestions or an idea of how I can fix this?
Thanks!
Admin access is needed if your app is installing into an area of the system where regular user does not have rights. If you want to be able to install it without having admin rights, it should install under their own user folder (think about %appdata%). Google Chrome is an example of that.
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.
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.