<2017 September>
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

On this page...

Search

Links

Member of...


ASP Insiders

MVP Visual Developer ASP/ASP.NET

Enter CodeZone

Blog Categories

Microsoft

Blogroll

Deutsche Resourcen

Management

Sign In
 

#  Tuesday, 30 January 2007

When you are working with Windows Vista, you know that even the administrative users are stripped ("filtered") of their privileges for normal operations, and that when you have to perform tasks requiring administrative privileges, you are presented with an UAC elevation prompt. The idea of this blog post series is to provide you with working samples on how to work with elevation from inside managed applications (you might also want to read Windows Vista Application Development Requirements for User Account Control Compatibility).

I want to side-step the really easy part - providing a manifest to start the entire application elevated (a good idea if the application makes no sense at all unless it has administrative rights, like regedit.exe). You can find information on those topics in Adding a UAC Manifest to Managed Code and Vista: User Account Control.

Now back to the topic of this post: App A needs to start App B with administrative rights (because App B e.g. needs to write to HKLM or Program Files). Therefore, we somehow must run App B as an administrative user (or with the non-filtered token of the current user). So how do we go about it?

First, some eye candy. You definitely already saw those nice shield icons before:

Those shield icons are stock on Windows Vista and indicate to the user that the action that hides behind the button requires elevation. I didn't create a button control myself - instead, I reused one that is readily available on the Web: Add a UAC Shield to your Winforms buttons in C#.

All I had to do myself was to start the Process ("App B"):

private void startProcess_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi = new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb = "runas";
  Process.Start(psi);
}

The ticket (so to speak) for the elevation prompt is setting the Verb to "runas" in the ProcessStartInfo instance - this will pop up the elevation prompt if necessary when Process.Start is called.

This simplistic approach has a problem though - once App B is started, users can switch back to App A, because it App B isn't "modal" for App A. To solve this problem, I incorporated the approach from Daniel Moth outlined in his post Launch elevated and modal too:

private void launchModal_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi = new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb = "runas";

  psi.ErrorDialog = true;
  psi.ErrorDialogParentHandle = this.Handle;

  try
  {
    Process p = Process.Start(psi);
    p.WaitForExit();
  }
  catch (Exception ex)
  {
    MessageBox.Show(ex.ToString());
  }
}

And that's it - App B is now modal. Once App B quits, control is relinquished to App A (which still doesn't run with administrative rights).

ElevateProcessSample.zip (21.1 KB)

Categories: Security | UAC | Use the source Luke | Vista
Tuesday, 30 January 2007 08:14:31 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]

 



Sunday, 04 February 2007 03:41:11 (W. Europe Standard Time, UTC+01:00)
Hey - I'm glad you found my UAC button code snippet to be useful. I'd like to make one minor correction: regedit is actually marked as highestAvailable, which means that it will adopt the highest privileges available to your user account. This way, standard users can still browse and edit chunks of the registry (like HKCU), but administrators will be prompted for consent so that they can read and modify the whole shebang.

Cheers,
Aaron
Comments are closed.

© Copyright 2017 Christoph Wille

newtelligence dasBlog 2.3.9074.18820
Subscribe to this weblog's RSS feed with SharpReader, Radio Userland, NewsGator or any other aggregator listening on port 5335 by clicking this button.   RSS 2.0|Atom 1.0  Send mail to the author(s)

 
Don't contact us via this (fleischfalle@alphasierrapapa.com) email address.