In Windows, if I refuse an app's UAC request, why must it not continue running?

Coming from a Linux/Unix background, I cannot understand how UAC works in Windows.

I heard that UAC works like sudo. My Linux application can do some other work before calling sudo.

But in Windows, it appears that all applications which require UAC confirmation must have UAC granted before doing any actual work at all! I run an application, it asks me for UAC confirmation and I refuse it - the application will simply not run.

So does UAC work like this?

sudo su
./run_app

Rather than:

./do_work1
sudo su
./du_work2

Thanks for everyone's great answer!

Solution 1:

When logging into Windows as a standard user, a logon session is created and a token containing only the most basic privileges is assigned. In this way, the new logon session is incapable of making changes that would affect the entire system. When logging in as a user in the Administrators group, two separate tokens are assigned. The first token contains all privileges typically awarded to an administrator, and the second is a restricted token similar to what a standard user would receive. User applications, including the Windows Shell, are then started with the restricted token, resulting in a reduced privilege environment even under an Administrator account. When an application requests higher privileges or "Run as administrator" is clicked, UAC will prompt for confirmation and, if consent is given, start the process using the unrestricted token.

From what I understand, what that last sentence means is that either the UAC dialog is displayed before the app loads so that it is started with the unrestricted token, or else if it is started with standard user privileges and needs elevated privileges in between for some work, it needs to get the user's consent and then spawn a new process which then runs with elevated rights. The token assigned when a process starts is what determines its rights. This token cannot be changed later, so if more rights are required, a new process needs to be spawned.

In this way, UAC is not exactly the same as sudo.

Solution 2:

Under Windows, the UAC prompt is triggered when you attempt to run an executable that is marked as requiring elevation in a manifest embedded in the file and you're not already running elevated. The behavior is more like setuid than su in that it's the file, not the command that tells the OS that the executable is to be run with different credentials.