Why you don't want to launch a process with a filtered token from a full token

Our team works extensively with ISVs on Vista application compatibility – porting XP applications to Windows Vista. We frequently get the question "How can I launch a program with a filtered token from a program with a full token?" Although there sure are ways to do this, there is a slight caveat with this scenario. What happens if a standard user is logged in and the program that requires admin privileges is launched? You will get the credentials dialog so that an administrator (e.g. member of the administrators group) can provide credentials for the program to run. The classic example is a child that wants to install a program but doesn't have the permissions to do so. In this scenario, a parent comes over, provides credentials to install the program and the child can then use it.

 

But what happens if from the elevated process launched by the parent, the secondary process is started under a filtered token? We have a process running with a filtered admin token of the parent running in the child's session and desktop. This possibly leads to all kinds of confusion (for example, program settings and documents go to the parent's folder, etc.) Clearly not a desired scenario. So what should we do?

 

One should have a small bootstrapper program running as the logged in user. From the bootstrapper, the elevated process can be launched for example with ShellExecute (the program either has to be manifested with requestedExecutionLevel or runLevel verb has to be specified). When the elevated process is done, the bootstrapper can then launch the second program with the reduced privileges of the logged-in user. In case the logged-in user is member of Administrators, all is well. In case she's just a standard user, all is well too.

 

Maarten