How to execute an app without elevation? - qt

I want to invoke an updater to check for updates (not to actually do the update but only check if there is any). I would like to do this in the background and silently. If there is an update, I would ask the user for elevated permissions and run the updater with that. The checking involves reading a file in the application's directory and comparing the version found in it with the one on a website.
How can I run it without elevation for checking only? QProcess::start() fails because it needs elevated permission and ShellExecute only works if I add the "runas" verb for the same reason (which I only want if there would be actually writing in that directory i.e. I want to perform an update). I'm guessing I need to add some sort of manifest but I don't know its contents.

So it turns out that I had another bug that caused the non-elevated running branch to run in all cases. The model I described in the post works. To avoid Windows infering the need for elevated permissions, you need to add a manifest resource. (for example, if the name of your application exe contains the word "updater" it will be triggered)
The contents of the manifest are the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Compiling it to your .exe depends on your compiler and environment, so I'm only showing mine: Qt Creator and mingw-gcc:
Create an rc file for the resources with the following content:
1 24 DISCARDABLE manifest.xml
Add this rc file to your .pro like this:
win32:RC_FILE = resources.rc
After this, ShellExecute without the verb paramter will run without elevation, and using "runas" will run it with elevation.

Elevation prompt appears when your application requests it, for some reason. You can control it with the application manifest. See Create and Embed an Application Manifest (UAC) article for details on how to add the manifest.
I would suggest you the following:
Separate your Updater and Update Checker, so that they're in different .EXE files.
UpdateChecker.exe requires no administrator privileges, and thus requestedExecutionLevel element of the manifest has asInvoker level.
Updater.exe requires administrator privileges because it writes updated application file into Program Files. Therefore requestedExecutionLevel element of its manifest has requireAdministrator level.
In your program you can launch UpdateChecker.exe whatever way you like. To start Updater.exe you will have to use ShellExecute; if the application has the manifest (and I strongly recommend embedding manifest) it will show UAC prompt for elevation if the application wants administrator privileges. There's no need to use runas verb.
Alternatively you can check whether update is available or not from your main application. And launch the Updater.exe only when there's a new version on the server.
Another option would be to make Updater.exe both check for update and apply it if there's one, just like you do it now. In this case Updater.exe should have asInvoker level in its manifest. When it starts, without parameters, it checks whether there's a new version on the server. If it finds newer version, it re-launches itself with administrator privileges and passes a command-line parameter, for example /doUpdate, which instructs it do perform the actual update.
In order to re-launch itself elevated, it has to use ShellExecute function and runas verb, because ShellExecute will be unable to detect automatically your Updater.exe now requires administrative privileges.
Keep in mind that the meaning of runas verb differs between Windows XP and Windows Vista/7, so you should handle this situation if you want to support previous versions of Windows. The first approach I described will work on Windows XP without additional handling.

I suggest to use one of these scenarios:
put that file in user's profile instead of application's path
copy content of that file to user's profile in case of it's in read only mode then run QProcess::start()
include that file inside .qrc file then extract it to user's profile in case of failing of read or run QProcess::start()

Related

How to retain folder permission during website deployment?

I have a production website that, once built in TFS is re-deployed and updated using xcopy. The entire site (excluding the root directory) it deleted then the new site copied in. This works well.
We use a 3rd party charting package that creates images at runtime and then renders a link to them. In order to do this it needs write permissions to a browsable folder.
Unfortunately, every time we update the website the write permissions of IIS_USRS is lost. Is there any way to retain this?
I guess it depends on what operating system the server is running, and whether you are building on the same server as you're deploying to, or a remote one.
The simplest thing to do is to put your xcopy command into a batch file, and include something like the following after the xcopy:
cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C
Or a more up to date option (I've not used this, so my parameters may be off):
icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M
Basically, either of those should give the user account that the site is running under modify (change) rights in the folder specified. This should be in addition to any existing rights on the folder, there are modifiers or switches to replace the existing rights.
If you are deploying to a remote server, you'll need some mechanism to run commands on there, we've found that PSExec works a treat (part of the PS tools from SysInternals).

Testing: I *want* to test web.config

I want to do some unit testing on one of my projects. This is a web project, and there will only be one copy of this program running aside from development copies.
I want to write some unit tests that will use the web.config. I understand that ordinarily, a tester would stub out this external dependency because he wants to test the code without the test depending on the web.config holding certain values.
However, the web.config in my project is supposed to always hold certain values and I want to have a unit test that will fail if they are set to invalid values. For example, one of the values is a SQL connection string.
I want to write a test that will read the connection string from the web.config. I envision that the test could connect to a server with the connection string and perhaps perform a very simple command like SELECT system_user;. If the command executes successfully and returns something the test passes. Otherwise, it fails. I want the connection string to be read from the web.config in the project I'm testing.
Of course, the ConfigurationManager will not ordinarily look for a web.config in another project. I could manually copy the web.config from the original project to the test project, but I would have to do that before every test and there is no way I could count on anyone else to do that.
How do I make my test project read the web.config from another project?
It sounds like you are trying to validate settings in web.config, which is a deployment-level concern and is different from unit testing.
Unit testing tells you that your core logic is performing as expected; deployment verification tells you that the application was installed and configured properly and is safe to use. Unit tests are meaningful to developers, deployment verification is meaningful to the end user or administrator that is deploying the app.
In situation like this I like to build a "system console" into my apps. This console contains a number of self-diagnostic checks such as:
Ensuring the connection string(s) are configured properly
Ensuring that any 3rd party services are available and functioning
Ensuring that all configuration settings are valid and won't cause runtime errors (e.g. paths exist, the web user account has read/write access where needed, etc)
I strongly recommend you consider separating this sort of configuration and deployment verification from your unit test suite. Not only will it simplify your work (because you won't have to load a config file from another project) but it's also the sort of tool that customers really, really like :)
You can load and explore other config files with the ConfigurationManager.OpenXXX() methods.
The WebConfigurationManager class specifically has a method for opening web.config files, and the documentation page I linked to has some more code examples. Once you have your configuration object loaded, you can explore it for sections and keys.
var cfm = new ConfigurationFileMap("path/to/web.config");
var config = WebConfigurationManager.OpenMappedWebConfiguration(cfm);
I asked a similar question that you might want to check out:
How do I test that all my expected web.config settings have been defined?
I ended up getting it working but the annoying part is my source control constantly locking the config file that is copied over. You can also rename the web.config to app.config so that it will compile into a non-web project.
It sounds like you're trying to squash a mosquito with a sledgehammer. Why not do this manually, as part of the deployment checklist; have a task to manually confirm the connectionString.
Or if you want to automate it, write a program to check the connectionString, attach it to your Continuous Integration server (assuming you have one) and fail the build if the connectionString is wrong.
Use Unit Tests for what they're intended for testing code, not configuration.
If you want to use original web.config file from your website to your Unit Testing project without copying it then you can Modify VS Local-Test-Settings.
Here is a step by step procedure to use ASP.net website configuration file under Unit Testing project. Follow the link http://forums.asp.net/t/1454799.aspx/1
There is a commercial tool called CheckMyConfig for validating .NET config files, which identifies settings within a given config file, and attempts to validate them.
Possible setting types include database connection strings, files, folders, IP addresses, hostnames and URLs.
The tool allows you to perform a number of checks including opening database connections, accessing folders, requesting a particular URL etc.
There is a standalone version, but the tool also has Visual Studio integration and a simple API that you can use to embed the tool within your own apps, in order
to perform a config 'sanity check' at app startup time.
In your unit testing project, add an app.config file and add the settings from the web.config file that you would like to use for your tests.

ASP.NET File IO Issue - System.UnauthorizedAccessException - stranger than you think

I am getting a strange issue where I seem to have read access, because I can
1. Get a list of files from a directory (Directory.GetFiles())
2. Load an XML document using XmlDocument instance's Load() method
But I can't use File.ReadAllText() to load a text file into memory. Gives me an System.UnauthorizedAccessException. I am not even trying to read from a network directory, just a local one. I've also used System.Security.Principal.WindowsIdentity.GetCurrent().Name to check the working user which is [CompanyDomain]/[MyUserName] and this user has full access to the directory I am using. I've also checked that the directory actually exists.
My environment
1. Windows Server 2003 Standard Edition
2. Visual Studio 2008
3. Just using the built in web server that launches every time i run the project.
Note: I couldn't find the IUSR_MACHINENAME user on this machine.
Any idea what steps I should take next?
Cheers,
James
One thing to assert:
the file that can be Xml Load()-ed is the very same file that cannot be ReadAlText()-ed ?
When things get odd like this, I found that turning auditing on, at the level of the directory or even of the file, often ends up pointing me towards a proper diagnostic and hence resolving the issue.
Also: In looking online reference for ReadAllText() I noted that (oddly, I think), this exception can be caused by:
path specified a file that is read-only.
Not sure why write access should be sought by this apparent read-only operation, but, maybe just try to make the file r/w-able.
http://msdn.microsoft.com/en-us/library/72wdk8cc%28VS.71%29.aspx
<identity impersonate="true" />

System.Security.SecurityException when writing to Event Log

I’m working on trying to port an ASP.NET app from Server 2003 (and IIS6) to Server 2008 (IIS7).
When I try and visit the page on the browser I get this:
Server Error in ‘/’ Application.
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application’s trust level in the configuration file.
Exception Details: System.Security.SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and the location of the exception can be identified using the exception stack trace below.
Stack Trace:
[SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.]
System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly) +562
System.Diagnostics.EventLog.SourceExists(String source, String machineName) +251
[snip]
These are the things I’ve done to try and solve it:
Give “Everyone” full access permission to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. This worked. But naturally I can’t do this in production. So I deleted the “Everyone” permission after running the app for a few minutes and the error re-appeared.
I created the source in the Application log and the Security log (and I verified it exists via regedit) during installation with elevated permissions but the error remained.
I gave the app a full trust level in the web.config file (and using appcmd.exe) but to no avail.
Does anyone have an insight as to what could be done here?
PS: This is a follow up to this question. I followed the given answers but to no avail (see #2 above).
To give Network Service read permission on the EventLog/Security key (as suggested by Firenzi and royrules22) follow instructions from http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx
Open the Registry Editor:
Select Start then Run. Enter regedt32 or regedit
Navigate/expand to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security
3. Right click on this entry and select Permissions
Add the Network Service user
Give it Read permission
UPDATE: The steps above are ok on developer machines, where you do not use deployment process to install application.
However if you deploy your application to other machine(s), consider to register event log sources during installation as suggested in SailAvid's and Nicole Calinoiu's answers.
I am using PowerShell function (calling in Octopus Deploy.ps1)
function Create-EventSources() {
$eventSources = #("MySource1","MySource2" )
foreach ($source in $eventSources) {
if ([System.Diagnostics.EventLog]::SourceExists($source) -eq $false) {
[System.Diagnostics.EventLog]::CreateEventSource($source, "Application")
}
}
}
See also Microsoft KB 2028427 Fail to write to the Windows event log from an ASP.NET or ASP application
The problem is that the EventLog.SourceExists tries to access the EventLog\Security key, access which is only permitted for an administrator.
A common example for a C# Program logging into EventLog is:
string sSource;
string sLog;
string sEvent;
sSource = "dotNET Sample App";
sLog = "Application";
sEvent = "Sample Event";
if (!EventLog.SourceExists(sSource))
EventLog.CreateEventSource(sSource, sLog);
EventLog.WriteEntry(sSource, sEvent);
EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Warning, 234);
However, the following lines fail if the program hasn't administrator permissions and the key is not found under EventLog\Application as EventLog.SourceExists will then try to access EventLog\Security.
if (!EventLog.SourceExists(sSource))
EventLog.CreateEventSource(sSource, sLog);
Therefore the recommended way is to create an install script, which creates the corresponding key, namely:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\dotNET Sample App
One can then remove those two lines.
You can also create a .reg file to create the registry key. Simply save the following text into a file create.reg:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\dotNET Sample App]
The solution was to give the "Network Service" account read permission on the EventLog/Security key.
For me ony granting 'Read' permissions for 'NetworkService' to the whole 'EventLog' branch worked.
I had a very similar problem with a console program I develop under VS2010 (upgraded from VS2008 under XP)
My prog uses EnLib to do some logging.
The error was fired because EntLib had not the permission to register a new event source.
So I started once my compiled prog as an Administrator : it registered the event source.
Then I went back developping and debugging from inside VS without problem.
(you may also refer to http://www.blackwasp.co.uk/EventLog_3.aspx, it helped me
This exception was occurring for me from a .NET console app running as a scheduled task, and I was trying to do basically the same thing - create a new Event Source and write to the event log.
In the end, setting full permissions for the user under which the task was running on the following keys did the trick for me:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
I try almost everything in here to solve this problem... I share here the answer that help me:
Another way to resolve the issue :
in IIS console, go to application pool managing your site, and note the identity running it (usually Network Service)
make sure this identity can read KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog (rigth-click, authorisations)
now change the identity of this application pool to Local System, apply, and switch back to Network Service
Credentials will be reloaded and EventLog reacheable
in http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx , thanks Michael Freidgeim
A new key with source name used need to be created under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application in the regEdit when you use System.Diagnostics.EventLog.WriteEntry("SourceName", "ErrorMessage", EventLogEntryType.Error);
So basically your user does not have permission to create the key. The can do the following depending of the user that you are using from the Identity value in the Application Pool Advanced settings:
Run RegEdit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
Right click in EventLog key and the select Permissions... option
3.Add your user with full Control access.
-If you are using "NetworkService" add NETWORK SERVICE user
-If you are usinf "ApplicationPoolIdentity" add IIS APPPOL{name of your app pool} (use local machine location when search the user).
-If you are using "LocalSystem" make sure that the user has Administrator permissions. It is not recommend for vulnerabilities.
Repeat the steps from 1 to 3 for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security
For debugging with Visual Studio I use "NetworkService" (it is ASP.NET user) and when the site is published I used "AppicationPoolIdentity".
I ran into the same issue, but I had to go up one level and give full access to everyone to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\ key, instead of going down to security, that cleared up the issue for me.
Same issue on Windows 7 64bits.
Run as administrator solved the problem.
There does appear to be a glaringly obvious solution to this that I've yet to see a huge downside, at least where it's not practical to obtain administrative rights in order to create your own event source: Use one that's already there.
The two which I've started to make use of are ".Net Runtime" and "Application Error", both of which seem like they will be present on most machines.
Main disadvantages are inability to group by that event, and that you probably don't have an associated Event ID, which means the log entry may very well be prefixed with something to the effect of "The description for Event ID 0 from source .Net Runtime cannot be found...." if you omit it, but the log goes in, and the output looks broadly sensible.
The resultant code ends up looking like:
EventLog.WriteEntry(
".Net Runtime",
"Some message text here, maybe an exception you want to log",
EventLogEntryType.Error
);
Of course, since there's always a chance you're on a machine that doesn't have those event sources for whatever reason, you probably want to try {} catch{} wrap it in case it fails and makes things worse, but events are now saveable.
FYI...my problem was that accidently selected "Local Service" as the Account on properties of the ProcessInstaller instead of "Local System". Just mentioning for anyone else who followed the MSDN tutorial as the Local Service selection shows first and I wasn't paying close attention....
I'm not working on IIS, but I do have an application that throws the same error on a 2K8 box. It works just fine on a 2K3 box, go figure.
My resolution was to "Run as administrator" to give the application elevated rights and everything works happily. I hope this helps lead you in the right direction.
Windows 2008 is rights/permissions/elevation is really different from Windows 2003, gar.
Hi I ran into the same problem when I was developing an application and wanted to install it on a remote PC, I fixed it by doing the following:
1) Goto your registry, locate: HKLM\System\CurrentControlSet\Services\EventLog\Application(???YOUR_SERVICE_OR_APP_NAME???)
Note that "(???YOUR_SERVICE_OR_APP_NAME???)" is your application service name as you defined it when you created your .NET deployment, for example, if you named your new application "My new App" then the key would be: HKLM\System\CurrentControlSet\Services\EventLog\Application\My New app
Note2: Depending on which eventLog you are writing into, you may find on your DEV box, \Application\ (as noted above), or also (\System) or (\Security) depending on what event your application is writing into, mostly, (\Application) should be fine all the times.
2) Being on the key above, From the menu; Select "FILE" -> "Export", and then save the file. (Note: This would create your necessary registry settings when the application would need to access this key to write into the Event Viewer), the new file will be a .REG file, for the argument sake, call it "My New App.REG"
3) When deploying on PRODuction, consult the Server's System's administrator (SA), hand over the "My New App.REG" file along with the application, and ask the SA to install this REG file, once done (as admin) this would create the key for your applicaion.
4) Run your application, it should not need to access anything else other than this key.
Problem should be resolved by now.
Cause:
When developing an application that writes anything into the EventLog, it would require a KEY for it under the Eventlog registry if this key isn't found, it would try to create it, which then fails for having no permissions to do so. The above process, is similar to deploying an application (manually) whereas we are creating this ourselves, and no need to have a headache since you are not tweaking the registry by adding permissions to EVERYONE which is a securty risk on production servers.
I hope this helps resolving it.
Though the installer answer is a good answer, it is not always practical when dealing with software you did not write. A simple answer is to create the log and the event source using the PowerShell command New-EventLog (http://technet.microsoft.com/en-us/library/hh849768.aspx)
Run PowerShell as an Administrator and run the following command changing out the log name and source that you need.
New-EventLog -LogName Application -Source TFSAggregator
I used it to solve the Event Log Exception when Aggregator runs issue from codeplex.
Had a similar issue with all of our 2008 servers. The security log stopped working altogether because of a GPO that took the group Authenticated Users and read permission away from the key HKLM\System\CurrentControlSet\Services\EventLog\security
Putting this back per Microsoft's recommendation corrected the issue. I suspect giving all authenticated users read at a higher level will also correct your problem.
I hit similar issue - in my case Source contained <, > characters. 64 bit machines are using new even log - xml base I would say and these characters (set from string) create invalid xml which causes exception. Arguably this should be consider Microsoft issue - not handling the Source (name/string) correctly.
My app gets installed on client web servers. Rather than fiddling with Network Service permissions and the registry, I opted to check SourceExists and run CreateEventSource in my installer.
I also added a try/catch around log.source = "xx" in the app to set it to a known source if my event source wasn't created (This would only come up if I hot swapped a .dll instead of re-installing).
Solution is very simple - Run Visual Studio Application in Admin mode !
I had a console application where I also had done a "Publish" to create an Install disk.
I was getting the same error at the OP:
The solution was right click setup.exe and click Run as Administrator
This enabled the install process the necessary privilege's.
I had this issue when running an app within VS. All I had to do was run the program as Administrator once, then I could run from within VS.
To run as Administrator, just navigate to your debug folder in windows explorer. Right-click on the program and choose Run as administrator.
try below in web.config
<system.web>
<trust level="Full"/>
</system.web>
Rebuilding the solution worked for me

Problem with workflow on SharePoint email enabled document library

SO ... here is the scenario ... i have a workflow on a document library that copies a file to a windows directory ... this workflow is set to be started at the time when a new item is added to the document library ... so everything works fine when you are manually uploading files to the doc library ... but the problem occurs when we use emails to populate the doc library instead of the manual uploading of files.
When an email is received ... the workflow starts successfully and runs properly (i have kept workflow history entries to check every section of code is being executed or not) ... the workflow stops when the section where the file is being copied to the windows folder is reached.
I basically think this is a problem with the permissions or access issues. Because when we upload the file manually (i.e. from doc library > upload) everything works fine. But maybe there is some other permission set which is used while an email is received by the doc library ... i have tried by assigning permissions to "Everyone" on the windows folder ... but no luck...
Can someone let me know which windows user account is used when an email is received by a document library? (i think its the IIS default account - but isnt it included in Everyone?? )
One solution which i can devise in my mind is that for the file transfer to the windows folder i should use temporary impersonation for the specific code segment (which writes the doc library file to windows folder) but any suggestions are welcome.
P.S. I dont have access to the server right now so i can only devise approaches in my mind ... cant test them right nw... so it would be good to have all suggestions u have so that once i get the access i can try all stuff :D
This is a well known situation. The system does not know who sent the email so it cannot impersonate a user it has no knowledge about.
Depending on which version of SharePoint you are running, the workflow may not start at all or it may start under the account that published the workflow.
For details see this Microsoft Support Article.

Resources