Wait for Administrative Level authorization of Helper Tool?

Targets Windows
1

I have 3 helper command line tools that I execute via a shell that are set to “Run as Administrator”. When my app executes these, the permission dialog pops up, but the shell doesn’t wait for the user’s response before continuing - the result is that these helpers fail so far as my app is concerned.

Is there a flag that can be set for the Shell class to wait for the user’s response to the elevation permission dialog before continuing? Or, a better way to execute the external helpers to allow the elevation to occur properly?

2

I’ve found out what’s happening - Xojo’s shell class is opening a cmd tool which then opens a new, elevated cmd tool which the first cmd tool simply exits.

This gets a very big “ugh” as there is no way for a Xojo Shell to collect the output from such a sequence.

3

Apparently, the defaults for executing an elevated cmd process do not allow for the sharing of stdin / stdout / stderr… Time to dig into named pipes on Windows. no such luck.

4

I have a named pipe implementation available here if that helps.

5

Thanks, Wayne. Looks interesting. Could you provide a quick implementation tip?

6

Hi TIm

You can basically treat it as a TCP Socket. I’ve been using it to communicate with a non-Xojo app without any problems.

7

Ah - so the task being executed must understand named pipes. Unfortunately, the tools that I need to use are locked to stdio, so no named pipes and MS doesn’t allow us to redirect the stdio channels of an elevated process …

This is getting more and more difficult with each OS update on all three platforms. Every platform now demands that we use helper apps to execute tasks from our user apps, but having no built in procedure for executing elevated processes within Xojo just adds to the frustration.

Feature Request time … <https://xojo.com/issue/32715>

8

MS has a justification for this: Why Microsoft wants us to really turn off UAC to get real work done (my title, not his).

I’m sure glad that MS is holding our hands on things like this. Goodness knows that we might end up creating User apps that are as insecure as theirs…

9

Have you thought about having a service app that launches these tools & reports back to your app via IPC? Any app launched by the service will have admin rights without the UAC issues. They are really easy to build with Xojo & debugging is now a snap.

10

I just got a response from another developer frustrated by this situation - “If you are providing a solution that must both interact with a user’s desktop environment (drag and drop, etc.) and access restricted devices, the only solution that we have found is to enable the “Administrator” user account and instruct your users to set an account password (the default is no password in Windows 7 or 8). This allows everything to work properly with a properly elevated SIP.”

She goes on to share how to enable the Administrator account.

This does work beautifully and as long as the account has a reasonable password assigned, it’s as secure as anything else on a Windows system.

To me, this seems a bit “sideways” in that I’ve never understood why the Administrator account was disable in Windows 7 / 8 and what the Windows version of UAC was about since the majority of users that it’s designed to protect simply click the “Continue” button when ever they see the Auth prompts… The only thing that I can see is that MS can now tell users “well, we warned you …”