'Run as administrator' issue

[Albert Wiersch]

So it seems one of my users was running the setup file using 'Run as administrator'.

It seems this was causing issues with launching my application from the [Run] section because it was not running under the proper user account.

I looked at the documentation for the 'runasoriginaluser' flag and it somewhat explained what was going on.

So what is the best solution for this? I was thinking I could just remove the option for the user to launch the app from the setup program if the setup program was run with 'Run as administrator'... but how do I do this?

Can I use a "Check" parameter? If so, what should the check function be so that it can detect whether the program was run with 'Run as administrator' or not?

Hope I'm on the right track. This doesn't seem to be a big issue but it would be nice if there was a simple solution other than entirely getting rid of the option to launch my application from within setup program in the [Run] section.

Thank you!

[Gavin Lambert]

On 18/06/2021 5:27 pm, Albert Wiersch wrote:
> So what is the best solution for this? I was thinking I could just
> remove the option for the user to launch the app from the setup program
> if the setup program was run with 'Run as administrator'... but how do I
> do this?

You don't. There is no reliable way to determine that the installer was
run that way. It's the same as telling any other process to run under a
different user account, but "different" is a relative measurement.
(There's a "run as a different user" option that behaves similarly.)

(It would theoretically be possible to compare the original and current
usernames, but currently the original name is not visible to the
installer itself -- and the names being the same or different doesn't
really tell you much by itself. At best, you might have an "are you
sure you want to run the app as user X" confirmation if they're
different, but this is an entirely valid thing for them to want to do.)

As you've read, when using "run app at end of install" then it will run
it as the original user (which was the admin if they "run as
administrator") -- but this is what they explicitly requested, so it is
behaving correctly.

If the user didn't want to run the app as the admin account, then they
shouldn't have told it to do that in the first place.

So in theory, you shouldn't change anything.


Having said that, you should verify what issues were happening as a
result of this. If the problem was that saving settings/documents
during the first run were lost by the second run -- that's expected and
not a problem (assuming that they come back when they run the app as the
administrator user again). Just remind the users not to do that.

If there was some other problem -- especially if the second run as the
regular user failed to work in some way, perhaps due to "missing" data
-- then that may be a bug in your app that you need to fix.

[Gavin Lambert]

Mere moments ago, quoth I:

> (It would theoretically be possible to compare the original and current
> usernames, but currently the original name is not visible to the
> installer itself -- and the names being the same or different doesn't
> really tell you much by itself.  At best, you might have an "are you
> sure you want to run the app as user X" confirmation if they're
> different, but this is an entirely valid thing for them to want to do.)

Actually that wouldn't help anyway, even if the information were
available (which it isn't).

Here's a quick rundown of likely cases:

1. User is an admin, and is not using Run as Admin:
* The usernames are the same.
* The original user is not elevated.
* The current user is elevated.
* "runasoriginaluser" will run the app as the admin user, not elevated.

2. User is an admin, and is using Run as Admin:
* The usernames are the same.
* The original user is elevated.
* The current user is elevated.
* "runasoriginaluser" will run the app as the admin user, elevated.

3. User is an admin, and UAC is disabled:
* The usernames are the same.
* The original user is elevated.
* The current user is elevated.
* "runasoriginaluser" will run the app as the admin user, elevated.

4. User is not an admin and doesn't use Run as Admin:
* The usernames are different.
* The original user is the non-admin, not elevated.
* The current user is the admin, elevated.
* "runasoriginaluser" will run the app as the non-admin user, not
elevated.

5. User is not an admin and does use Run as Admin:
* The usernames are the same.
* The original user is the admin, elevated.
* The current user is the admin, elevated.
* "runasoriginaluser" will run the app as the admin user, elevated.

6. User A uses "run as user B" (where user B is an admin):
* The usernames are the same.
* The original user is user B, not elevated.
* The current user is user B, elevated.
* "runasoriginaluser" will run the app as user B, not elevated.

7. User A uses "run as user B" (where user B is not an admin), then UAC
elevates as user C:
* The usernames are different.
* The original user is user B, not elevated.
* The current user is user C, elevated.
* "runasoriginaluser" will run the app as user B, not elevated.

As you should see, most of these cases are indistinguishable, and none
of them are really incorrect -- it's just doing what the user explicitly
asked for.

[Albert Wiersch]

Wow. Thank you for the detailed reply.

Since you said I shouldn't change anything then I won't. I'm glad to know it really working as it's suppose to.

Thank you!!

Albert

[Laurent Combémorel]

Hi

Gavin's explanation is quite interresting...

But for your point... " So it seems one of my users was running the setup file using 'Run as administrator'." : if it is not needed to 'run as administrator' for installation reasons, which seems not to be the case as this user seems to be the only one to do it, why not just remove the ability to do so ?

[Albert Wiersch]

An interesting thought... but I believe that running as admin allows the program to be installed for all users on the system.