Windows elevated permissions and app design catch-22

Targets Windows
1

I’m porting an app to Windows and have run into an issue with elevated permissions / RunAs.

Because the app uses back-end helpers, requires access to system hardware, but still requires normal UI operations (drag and drop, path parsing) at the user level, I’m kind of stuck trying to come up with a total solution that doesn’t require forcing users to enable the actual Administrator account on their systems.

Here’s the rub -

  • If I don’t use elevated permissions, the back end helpers can’t access the disk and tape low-level devices, and there’s no way to lower the access requirements on the devices.
  • If I just set the back end helpers to run with administrator privileges, I can now access the hardware, but the shelled process can no longer communicate with the UI.
  • If I run the entire app as Administrator, the user can no longer interact with their desktop or explorer.

I’ve also tried using named pipes, but these seem to be 4th class citizens on Windows platforms and the communication performance is painfully slow and actually interferes with the performance of the helper tools.

The back end helpers can’t easily be modified for IPC style communications.

Does anyone know of some internal app authorization steps on Windows that could allow this to work transparently after the user authorizes the elevated permissions?

Thanks

2

You could split your UI functionality into two parts (projects). The UI and a helper that communicates with the back end helpers. These two projects would communicate using IPC. Launch the helper using http://developer.xojo.com/elevating-user-access-control.

Bit of a kludge I know, but it should work.

3

its worth noting that this may not be allowed either as direct communication across privilege barriers is also sometimes restricted.