RunAsUser
Back in the Windows Vista timeframe, the existing RunAs verb for ShellExecute was changed. Instead of prompting the user to run the target as a different user (e.g. the experience you get when you Shift-Right-Click on an app) it instead would treat the call as “Run the target as an Elevated Administrator”. Well, what if you wanted the old experience, where the user was prompted for an account to use?
It turns out there’s another (as far as I can tell, undocumented) verb, RunAsUser that has the old behavior.
This trick has been integrated in SlickRun 4.3 and you can use it by hitting Ctrl+Alt+Shift+Enter when executing a command. The existing Ctrl+Shift+Enter shortcut for “Run as Administrator” remains unchanged. You can also configure any given MagicWord to always prompt for a user-account to use via the new checkbox at the bottom:
Launching Unelevated
A longstanding problem with SlickRun was that the Setup program launched it when installation was complete, and because the Setup program runs as Administrator, SlickRun itself ran as Administrator. And when SlickRun runs at Administrator, everything it runs launches at Administrator as well. This has horrific consequences for things like Internet Explorer, which disables its sandbox when run as Administrator. It’s just awful.
So, you’d expect that ShellExecute would’ve been updated to offer some sort of RunUnelevated verb that enabled an elevated application to run a target application without elevation. Sadly, it doesn’t; the Windows team considered this a really hard problem (the corner cases are ugly) so they punted on solving it. The problem with this approach, of course, is that leaves solving the problem to the poor ISV developers, who have even less understanding of how to solve it, and thus they typically don’t even bother trying, leaving their users at risk.
Fortunately, a while ago I discovered an ugly hack that works everywhere I’ve tried it. A kind developer on the Shell team confirmed that the fact that this works is basically a bug and they could remove it at any time. But they haven’t yet, and compared to the (absurd) alternatives, I think it’s the best option for most of us.
The trick is simple—just execute Explorer and pass in the path to your application. In a NullSoft Installer Script, it looks like this:
exec '"$WINDIR\explorer.exe" "$INSTDIR\sr.exe"'
There are, of course, corner cases where this could fail (e.g. if the user isn’t using Explorer as their Windows shell) but in the last few years I’ve been using this trick there have been a total of zero complaints.
The famous Raymond Chen has provided a more robust approach that asks Explorer to launch your app for you, depending on COM rather than the “bug”, but that approach is only feasible if you can call arbitrary native code, which is rather complicated for NSIS scripts.
-Eric Lawrence
text/plain 