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.
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.
I'm a programmer not an admin. I significantly modified an old program written in 1997 to run under Windows XP ~7 years ago. At that time, I rewrote in VC++ 2005. The local production network has been updated to Win7. Program updated to VC++ 2010.
Problem: Program runs in new environment but only if user has admin privileges. Without, needed files cannot be accessed. Attempted Fix has been to give user group access to the needed files. Users can access the files "by hand" but program still fails.
Is there a way to give the application admin privileges so that it can access the files?
Not acceptable is allowing users to run as admin. We have to operate under DoD constraints. Is there something I as the guy working on the application can do? If not, what is the solution?
Recap: problem was a large number of scratch files which, in the original application, were being written to the C:\ root directory. The solution was to use "getenv_s" to obtain the user's directory via an environment variable. The pathname was modified such that the string returned from "getenv_s" was concatenated with the scratch file name. Laborious but problem solved.
The huge difference between XP and Windows 7 is the access system (user access control entered with Vista and was further refined in 7). In theory you could run the application as an admin user, or provide a service that would access the necessary system components and files as an admin user. But there isn't a way of giving an application itself extra permissions.
Your other option is to find out what specifically is causing the problem and correct that in your application. Chances are this is a system file or the like.
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 written a WPF application.
When it is installed on client machines, they are prompted for a username and password so that they have administrator privileges to use the application.
I need administrator privileges because my application opens ports and writes files to the file system.
Is it possible to allow any user to run the application without being prompted for an administrator username and password and to elevate the application to run with administrator privleges?
Thanks
When your app is installed, it will prompt for admin rights if the installation program has been marked for admin execution. This is normally only required if you want to install to a location available to multiple users, such as within the Program Files folder hierarchy. An MSI will raise a UAC prompt by default, but it's easy to make an MSI with WIX that doesn't raise a UAC prompt.
When your app is run (by a user without admin rights), it will ask for admin rights if the app itself has been marked for admin execution. This is partly under your control, but can overridden by users on the client machine.
An app that writes to file system folders doesn't require admin rights as long as the user running the app has permission to those folders. Generally you can make this work by writing to a location that's accessible to each user.
However, I believe that opening a port does need admin rights if the app is doing anything more than querying statistical information.
If your app does need admin rights to run, and you don't want your non-admin users to see a UAC prompt during program execution, then I suggest you divide your app into 2 parts.
The first part is a Windows service that runs under a privileged user such as LocalSystem and is configured to interact with desktop programs. This service does all of the admin-related tasks, and will need to be setup by an installer that requests admin rights.
The second part is the WPF program that doesn't do anything privileged. If you mark this WPF program as not needing elevation, your end-users will never see a UAC prompt when running it, because all the privileged work is being done by a service that's always running.
I need to forbid to uninstall an application (not a service!) by a user w/o some special rights. How to do this? installation will be done by domain administrator
thanks for your time
[EDIT] also I need to prevent removing the application from windows startup
[EDIT1] to clarify: application is simple and is installed in its folder and added to windows startup (actually to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry). What I need exactly is to forbid to remove this folder and this registry key, for ordinal users, not for local admins.
[updated]
the file location is easy. That is simple revoking write permission on the folder and all its subfolders and files for Builtin\Users, and giving Builtin\Administrators full permmision. You can set this via the Explorer, properties-> permissions or commandline wise with cacls (or icalcs if you're on win7)
The regkey is on my win7 box already only readable (not writeable) by Users and read/write by local admins (regedit -> Context menu -> Persmissions).
If it still doesn't behave like you want figure out what groups a normal user is in (also domain groups) and then check how those groups are propagated to the local machine.
And as sugested by Ben in the comments, you might start a new question on Server Fault.
[end update]
[before edite response]
I doubt you can disallow the uninstall of 'one' application. By means of a Group Policy you can "Pohibit removal of updates"
(in GPedit.msc under Computer Config/Admin templates/windows components/windows installer)
The Group Policy is set by a domain admin and is enforced across the domain so it doesn't require 'persmissions'. But you need off course to also prevent local admins from editing the local group policy.
Another more daunting option would be to use a group policy in the Software Rectriction part of Security Settings. Here you can enter a path policy for the name of the msi or exe file that you do not want to be run.
Both require validating/testing to prevent that to much restriction prevent everybody from starting anything...
If an application requires administrative rights to be installed, then non-administrators will not have permission to remove it.
If the users have local administrative rights, then you can't prevent anything.