Here is the issue that I am having,
I have a C++ application that runs by writing data to .txt files and I want to create an MSI Package for the application.
When I build and run my app all is fine but when I run my MSI Setup File the created application does get granted the correct privileges to function.
I can't find a way to allow the app to write to the .txt files needed even if I include them in the package and set them as system files.
If I "Run as administrator" all is well but that isn't really plausible as I need it to function while "Running as User".
Is there anyway to prompt the user while installing to agree to an install with admin rights, so it doesn't have to be done manually before a prompt each launch.
Anything that can get my code running again would be brilliant, thanks.
Longer Writeup: System.UnauthorizedAccessException while running .exe under program files (several other options in addition to the ones listed below).
Per-User Folder: I would think you should install the files in question to a per-user folder (writeable for user - for example My Documents), or as templates to a per-machine folder (not writeable for normal users - for example %ProgramFiles%) and then have your application copy the templates from the per-machine location to the current user's My Documents folder - for example. Then you write to the files there - where a regular user will have write access. I suppose you could also write to a network share which is set up for users to have access.
Elevation: It is possible, to require the application to run elevated (link might be outdated - for .NET it is slightly different), but this is a horrible approach for something as simple as writing to text files. I would never require such elevation. Elevated rights are pervasive, and you don't want your application to run with the keys to the city - you become a hacker target and bugs in your tool become armed and dangerous.
ACL Modification: It is also possible to install the text files to a per-machine location and apply ACL permissioning to them so that they are writeable for regular users even if they don't have elevated rights. There is some information on how to do this here (bullet point 2). This approach is frowned upon in this day and age, but it will work. Be on the alert that your ACL permissioning shouldn't be too tight, in case you write to a new file, delete the old one and rename the new file to the old name during your write operation - you need file create in addition to file write obviously - there is very fine-grained control in NTFS. GenericWrite should do the trick I think.
Some Links (loosely connected, added for easy retrieval):
Create folder and file on Current user profile, from Admin Profile
Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
Create a .config folder in the user folder
There is no connection at all between the install of an application and the running of an application regarding privileges. In other words there is nothing you can do in an MSI install that grants elevated privileges to the app being installed. It would be a massive security breach if a limited user could create an MSI setup that then installed an app that ran elevated.
So this question is actually nothing to do with Windows Installer - it's about whether you require users to be limited users or elevated users. If it's acceptable that users must be privileged, then you give the app an elevation manifest. If limited users will use it, then all writes or modifications to files or registry entries must be to locations available to limited users. It also means that the app won't be able to perform privileged operations, such as starting or stopping services.
Related
I have a multi-process application that was originally developed in XP and was originally designed with no regard to administrator privileges. We used to configure and sell computers with the software. We are now selling the application by itself, without the hardware, to be installed on user systems in a corporate environment. Currently our software package requires our users to run in administrator mode, which is not making us popular with our customers IT departments.
I have been working to remove items that obviously require administrator privileges (writing to HKLM in the registry, writing to the Program Files folders). However, Windows continues to require administrator rights to run the software. If I deny the rights, it closes with no logs. It has a lot of legacy code and so hints to find where the administrator access is happening has proven difficult.
Is there an easy way to see what is being accessed or done that is hitting Windows 10 admin requirements?
Currently I have removed moved writing of data files I could identify to the Program Data folder or to user documents. (depending on whether I want users to be able to easily find them or not).
Configuration files have been moved to user folders.
Registry key access has been kept to HKLU or read-only in HKLM.
Thank you all for the help. I ended up finding the answer in the C# based launcher for our software, which was starting all processes with the verb "runas" set:
try
{
myProcess.StartInfo.Verb = "runas";
myProcess.StartInfo.FileName = command;
myProcess.StartInfo.WorkingDirectory = workingDir;
myProcess.StartInfo.Arguments = prams;
myProcess.Start();
}
catch (Exception ex){}
I removed the "runas" verb and now the system is not requesting admin privileges on the started pieces of code.
I found the cause when I tried to setup a debug run from the Program Files directory and started the code without going through the launcher. (started in a debugger) The system did not request administrative permissions which led me back to the launcher. I recently got the launcher to run without needing administrative permissions and so I had assumed that the problem was in the other processes. Seems I was mistaken.
I maintain a large Windows C++ Application that installs with nullsoft nsis. Installation is quick and simple (less than 1 minute).
Some users in large companies do not have administration privileges and they have to order costly 3rd party services to update their installation. Therefore some of them only update once a year, while we ship every month and sometimes fix important bugs etc.
So we are thinking about automatic updates that do not require elevated administration rights. Mozilla and Adobe do this as well as others. As far as i can see an the Mozilla XULRunner site they install a service which then in turn can run a update without forcing the user to enter a administration password. I also found Googles Omaha but it is not clear about the administrator privileges ("Support for restricted user environments; for example, users without administrator privileges "..."This requires the user has administrator privileges.").
So far i have not found exact answers to these questions:
What steps do we have to take in order to establish such a mechanism?
Can we keep on with nsis?
What server infrastructure is requested?
Your application should check for updates on your server/website and get the download link.
This should be pretty easy if you maintain a text file/page with fixed hyperlink.
This hyperlink can be hard-coded in your application.
If it detects a version newer than the current version then download the files.
Along with these files there should be instructions for which files to replace and Which files are to be added at what location, etc.
Now whether or not you need admin privileges depends on where you need to place the updated files. If the target folder has some restrictions then it would be difficult to update in the same session. So you may have to launch a dummy exe which asks the user for admin privileges during startup. Now you can copy the updated files to your desired location without much pain.
I am trying to release a C++ .Net application and am getting very frustrated with Windows UAC. I have not much experience with this as have always been writing for XP.
The program needs to update some properties that are stored in two XML files and every time it tries it gets access denied if it is not running with an Administrator account.
I have followed the recommendations from Microsoft and am writing all the files that need to be modified to the CSIDL_COMMON_APPDATA folder. The installer has an action that creates the [Organization}[Program] structure within the later and adds the security group Every One with full control privilege because by default, that directory is read only.
I have verified that the cretated directory [Organization}[Program] does actually contains the group and the privilege assigned after installing.
Also, the application has a manifest with a requestedExecutionLevel, which I have tried asinvoker and Highestavailable.
The application is still not being capable of writing to the directory unless the user is not logged as Administrator...
The machines are in a domain controled by a server 2003 but the clients are a mix of XP, vista and 7.
Please, could someone with more experience in this than I enlight me?
Should I use some other folder? The problem is that Different users might log into the computer and those settings are common, therefore the obvious User folder is not an option.
I cannot either add the user to the security of the folders with the installer because I don't know which user from the domain will use the program and I cannot do it from the program when starting because if the user does not have adminstrator rights the program will just be blocked.
Please, any advise or indication about what am I missing here?
This may discuss your problem. See especially
Your application's installer needs to set ACLs on your subdirectory of CSIDL_COMMON_APPDATA to allow users to access that directory as required by your application
I have a problem with UAC on Vista/7. My installer with UAC Execution Level = requireAdministrator installs and runs my app. App UAC Execution Level = asInvoker. So first time app runned by installer -- it runs as administrator. Then, app creates some files to store self state. Later -- if app launched by user, not as administrator -- app can only read from created files, but can't overwrite them.. I tried to disable UAC in the app manifest, or build app without manifest but result still same -- every file created when app runned as administrator can't be overwritten when app runs as user. I tried some other installers like Inno Setup but there nothing like my problem... So my question -- why it happens in my case and how to fix it ? Thanks.
P.S. Important notes
1. Actually it is not installer. This is utility to update main app executables. Main app check server for updates, if any available -- downloads updates to the temp folder and then launch utility with elevated rights (http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx) in order to replace executables in the Program Files folder. Main app terminates just after launching utility.
2. All files application stores in the ProgramData\myAppName folder.
Are your installing application for current user only or for all users on the machine?
For per-user installation it makes sense for the installer to create initial application state in the user's AppData folder. MSI runs per-user installations NON-elevated, so there is no problem with files in AppData folder your applications cannot modify.
For per-machine installation it does not make sense to put anything to the specific user's AppData folder or anywhere under users profile location. New users can logon on the machine after application is installed and they would not have anything there.
That said, you have three solutions (actually two solutions and one hack):
Use per-user installation. Set ALLUSERS=2 and MSIINSTALLPERUSER=1. Your MSI will be run non-elevated. MSI is free to put any state files in AppData folder.
Use per-machine installation. Don't write to users's appdata. Instead, write initial state files into %ALLUSERSPROFILE%. They will be Read-only to application. Modify your application to copy initial state from %ALLUSERPROFILE% to current user profile on first run.
Add custom action to your installer to add user to ACLs.
(#3) is a hack and I don't recommend it, because your application would be broken for new users, or when user re-creates his profile on machine.
You should not start your main app elevated if it doesn't require administrator rights. What type of installer do you use?
MSI runs with current user privileges and elevates only to make changes to the system. After installation completes, you can start your main app and it will be run as the current user, non-elevated.
If you custom setup.exe, you can start your setup program non-elevated. When the time comes to install files, start another process (it can be the same executable) to install files and make system-wide changes. When this step completes, you can re-start your main app as non-elevated from the initial process.
Alternatively, with your current approach where setup and updater run elevated, follow the instructions at How do I start a program as the desktop user from an elevated app to start your main app non-elevated.
Note: the default permissions on ProgramData allow everyone to create files and folders but only the user that created them can modify the files (or administrator). To overcome this, you have two options:
Create data files directly in user profile. Each user will have their own data.
Create user profile data from common template stored in ProgramData, as suggested by Seva in option 2. In this case each user will also have their own data.
Or modify ACLs on your application data in ProgramData directory to allow its modification by everyone, not just the user that created the folder and files.
im writing an application that downloads and installs addons for programs which needs to save the data to program files (for the programs in question). Now this works fine on xp and vista with uac disabled however it is failing on normal vista due to the virtual folders.
How would one get around this with out needing to request admin rights every time the app started?
P.s. Program is written in c++, vis 2005
Edit: File system virtual folders: http://www.codeproject.com/KB/vista-security/MakingAppsUACAware.aspx
Only write to Program Files during installation. After that, write to the user folders.
You can elevate the apps privileges later, but you'll just be delaying the prompt. The whole point of UAC is to prevent random apps from writing to folders that require admin privileges. (ok, not the whole point, but a large portion of it.)
You could create a service with admin privileges and send commands to it to move the downloaded files into the desired target directories, but this opens up a user's system to being abused by other apps if you don't design it very carefully.
This article talks about getting apps to work nicely with UAC. Also, see this article here.
Microsoft recommended to me when I spoke to them to have to write a second application, which you manifest as requiring administrative privileges. You use this application to deploy your file from a safe location (such as the users programdata directory) to the program files directory (Note that if your DLL isn't signed then this is a massive security hole as a virus/malicious user could manipulate the file before your function call).
Your non administrative app can call this application which will trigger UAC. People who understand UAC won't care and happily will click your application. Those who hate it will have switched it off. The call to start the new process (which required admin privileges) will throw a win32 exception if the user cancels the UAC dialog so beware to catch that.
The problem in vista is that it tries to help you by virtualising your program files directory if you are not admin. By design there is NO way that you can write to the program files directory unless you're administrator.
Another option is to create all of your "updates" as MSI updates. That way the windows installer will trigger UAC for you and you could provide a logo for your software etc.
Option 3 is to use clickonce deployment which will allow you to automatically update your program without UAC but you live in a sandbox on the users system which may not work with your application's current design.
I got around uac by making a windows service that does the work i need and only runs while the app is running.