Elevated Permission With Non-admin User Context

[Harsh Agarwal]

Hi, So i am developing an application which requires admin access for some operations. So i decided to create a win exe that requires admin privileges to start and when it started i used ipc to perform all o/ps that require admin access. This way i ask user for admin credentials once and get all my o/ps performed. Now what issue i am facing is that when i give admin credentials the exe starts to run with admin's user access token. Now i can only have one exe running for all users this way. So i want that my exe should have the same access as admin but it should run in my current user context i.e. my exe should create its applicationData in %AppData% but it should be able to access resources which require admin access.
Is there a way to achieve this

 

[ChatGPT]

Hi Harsh,

This is a classic case of the limitations imposed by Windows' UAC and token architecture. When you elevate a process (via a manifest or otherwise), Windows replaces the current access token with an elevated one. That token carries all the privileges of the administrator account—including the administrative profile (which affects things like %AppData%, registry hives, etc.). In short, once you launch your executable as elevated, it’s running under the admin’s credentials and environment.

What you're essentially asking for is to have the best of both worlds: an elevated process (for privileged operations) that still “behaves” like your regular user process (i.e., using the current user's profile). Unfortunately, Windows doesn’t support a single process running with a split token (i.e., mixing admin privileges with a non-admin user context).

The typical and recommended approach is to use a split process architecture:




- Create a “broker” or “server” process that runs with elevated privileges. This process is responsible solely for performing operations that require administrative access.

- Run the main part of your application (UI, application data storage, etc.) in a non-elevated process, which operates normally with standard user rights.

- Use an IPC mechanism (named pipes, RPC, etc.) for secure communication between the non-elevated client and the elevated server.


This way, the non-elevated process maintains its user context (e.g., correctly using the user’s %AppData%), while the elevated process handles the privileged tasks. Many well-designed Windows applications (including installers and update systems) use this sort of approach.

While there are some workarounds or “hacks” that people have tried over the years, they typically involve unsupported techniques that come with a host of security and stability risks. Relying on officially supported patterns, as described above, is your best bet.

I hope this clears things up. If you have further questions or need assistance designing the IPC mechanism or split process architecture, feel free to ask!

Regards,
ChatGPT