I have one major problem with my app. I have an app & updater as a separate exe files. When an update is available, updater does the update, and on process completion it starts my app. The main problem is - app is installed in program files folder, so updater need UAC admin privileges, and that's ok, but when I need to run my app updater needs to run it as a normal user, because if it's run as an administrator drag and drop doesn't work (not an app problem, UAC blocks it). I've tried several different solutions, and even this one:
How to run NOT elevated in Vista (.NET)
It haven't helped me - my app is run as an administrator.
You'd better avoid starting a non-elevated process from an elevated one. It's tricky part and error-prone.
This approach is better:
Your updater initially starts as non-elevated application, and its manifest has asInvoker level.
When it starts, it restarts itself with elevated privileges using runas verb, and passes a command-line parameter to indicate it. This instance performs the update and returns.
Here comes the non-elevated updater again, and starts your application with the same non-elevated user token that started the first instance of updater in step 1.
Pretty simple and robust.
Look at this post on how to Enable Drag and Drop for an Elevated process. Even though it says MFC app you can cll those Windows API in Any app I suppose
https://helgeklein.com/blog/2010/03/how-to-enable-drag-and-drop-for-an-elevated-mfc-application-on-vistawindows-7/
Related
I am building a winforms app that inspects processes as part of its routines. I am only getting a few details from the running processes, such as MainWindowTitle, name, executible etc.
I see on some processes this cant be accessed. I know system processes cant be inspected in detail, but it seems like the ones I cant access, being normal processes, happens because they are being run as Administrator.
I run my visual studio as Administrator, and if I don;t run my compiled app as Admin, I simply cant get any details from the Visual Studio process.
On the flip side, with Management Studio for instance, I don't specifically run it as Administrator, but if I don't run my compiled app as Administrator, I cant inspect the Management Studio process.
Does Management Studio somehow run elevated, without bugging me? (That's what I want to accomplish in my own app)
What I am looking to do so far:
I have looked at the possibility of running my app elevated using a manifest, but I don't want my whole app to force Admin privileges access on to someone that does not like that..
Is there a way for only the routine that inspects my processes, to run elevated, but not to bug the user each time that it runs (Several times/minute).
Can I run my process inspection routines in a separate thread, and elevate that thread without bugging the user..
Can I do something similar to Task Scheduler, where you can specify the admin account to use in the (Run task as) section? This way the user can be prompted for their password (preferably by the system), and not be bothered the next times it runs.
Any ideas on the subject?
I have a C# application that needs to run with administrative permissions. In particular, it loads at Windows 7 start-up and executes a few scripts in the background. This process is fully invisible to the user and is covered up with a background when executing. The permissions implementation is via a manifest file. Now, the problem is that I need to automate the step where UAC prompt comes up, and invisibly accept it.
How would something like that be done in C#?
I think what you have to do is impersonate a user with administrator privileges.
Try this: http://msdn.microsoft.com/en-us/library/chf6fbt4.aspx
I have had success with this method before, give it a shot!
I am creating a software that require run as administrator when run, most client already aware of it and running it without problems. However this software require to run another software using Process.Start call it SoftwareB. When running SoftwareB, softwareB also require elevated privileges. How do I run softwareB without asking the client for UAC again, because the softwareB should be running in background and the software might be running it when user is not attending the PC.
If you call Process.Start from elevated process, then new process will be elevated as well.
Basically, I have an application that is installed on the users computers.
The users are on Windows 7.
The users are NOT given admin access.
The application, however, needs to be able to save files to its own Program Files directory.
The path I wanted to take was:
Download various binaries (web service).
Write binary to files in temporary folder.
Launch a console app. (Console App waits for the main app to shutdown)
Console App copies the temporary files to the Program Files directory.
Console App relaunches the main app.
Console App shuts down.
The problem is that I know Windows 7 does not allow applications that are not running as administrator to write to the Program Files directory, and I understand why (for security), but since I am writing this app myself, installing it on the machines myself, is there any way to make my app be able to write to whichever directory it resides in (platform independent because it uses relative paths) without having a popup box ask to run the app as admin? Can't the app be signed to ALWAYS run as admin?
In fact, I don't even need the main application to be the one that runs with administrative access. I need the console-app (the one that copies the temporary files) to be able to copy those temporary files as permanent files.
Update: Yes, this is for an auto-updating application. I thought about ClickOnce and the such, but there are additional requirements which lead me to create my own internal updating, mainly because the updates need to be silent and piece by piece. Sometimes (depending on the pieces updated) the application needs to shutdown, move the files in, restart. Other times the application simply needs to move the files in and continue running.
ClickOnce just didn't work for my situation, and our organization was looking for something in-house so it can be customized to fit our future needs.
As the comments already pointed out: ProgramFiles is inaccessible if you have a somewhat recent version of Windows (Vista+), UAC enabled (the default) and non-admin users.
Your updated question says that you need to update (at least parts of) your application and that might need a restart. You created your own way to update the modules.
My suggestion is the following: Don't write to ProgramFiles
Either install your application completely to the user profile or split it up.
I'd try to create an executable that does very litte:
Sets up shadowing so that assemblies are not locked
Look up an assembly in a writable location (ProgramData or in the user profile) and load it
Run the app from there
In case of an update you can overwrite your assemblies (since they are shadowed and stored in a sensible location) and, if necessary, stop the program/ask the user to relaunch/implement a restart mechanism. You shouldn't need administrative privileges for this.
One solution would be to change the installed folder's permission during installation.
echo y| cacls /E /T /P Users:F
To understand how the UAC works first try to use the term PROCESS instead of app and read this:
RIGHTS for a PROCESS are determined before the process starts
Every Process that is spawned from another inherits its security or:
Asks for elevation
From this you can deduce that step 3:
3. Launch a console app. (Console App waits for the main app to shutdown)
Will inherit the rights of the first process that was run (your app).
At some point you will need to ask for elevation. If that is before your app is run or before running asubprocess, is your choice.
The most user friendly way to do this is to modify folder permissions once at first start or installation. That is a way to not bother the user each time. But some UAC will surely pop to the user at some point.
We have just discovered that code that calls the Win32 SetDateTime function needs to run in elevated mode in Windows 7, i.e. even when logged in as an administrator, one still has to choose to run the Set Date code as Administrator for the call to change the date.
Is there anything I can do in code to always call this function under elevated privileges?
You can use the ShellExecute API call to launch an executable with elevated privileges.
However, if UAC (user access control) is enabled on the machine, the user will still get the UAC prompt asking for permissions to run elevated.
So I don't think you can avoid the prompt for elevation permission, but at least your user doesn't have to manually run the program as an admin.
Please let me know if you need help in how to launch an executable as an admin.
This is just not how security works. Changing the clock is a very intrusive operation, it has a very large number of side effects. There is no mechanism in Windows, or any other operating system for that matter, where you could start a process with limited privileges and then just arbitrarily bypass these limitations and suddenly gain administrator rights. There wouldn't be any point whatsoever to running programs with limited privileges if that was possible.
If you want to do something like this then you'll have to run your program with elevated rights. On Vista and Win7 that requires you to run as a service or a scheduled task. Which require an administrator to get installed. UAC provides a way gain admin rights for regular programs, you have to include a manifest in your program so the user is notified about your privilege elevation. Google 'requireadministrator', take the first hit.
Like others have said, you need to spawn a new process to get elevated permissions, which will result in a UAC dialog.
If this is something you need to run unattended you could try running as a service. That would give you the elevated context you need.