"RUN AS ..." may destroy Windows\System32

[alan_b]

When you use "RUN AS .." on a script selected by a third party "Windows Explorer" you may destroy the contents of C:\WINDOWS\system32.

It may certainly do this with a batch script that uses CMD.EXE.
It is possible that the problem also applies to ANY EXECUTABLE that may be similarly launched.

I have a third party explorer that launches CMD.EXE and gives it the name and path of the selected file.
If I double clicked then CMD.EXE has its home changed from its location, i.e.
C:\WINDOWS\system32
and is instead set to target the folder containing the script, so that a command
DEL *.EXE
will only zap the EXE files that are in the same folder as the script.

Unfortunately when launched via "RUN AS ..." there is no change to the home location.
In my case the script merely wanted to change a INI file that was a companion in the same folder as the script,
and instead CMD.EXE was trying to locate and change that file in Windows\system32. Bad Move.

I had to add this to my script before I could successfully use RUN AS ...

Code: Select all

CD /D %~dp0

You may wish test any third party "Windows Explorer" that you use to select and "RUN AS ..."

HARMLESS Test Code

Code: Select all

@ECHO OFF
ECHO %~0
CD
PAUSE
EXIT

My result of RUN AS with Windows Explorer :-

D:\_T\D3\Clean30\V\Y\Harmless.bat
D:\_T\D3\Clean30\V\Y
Press any key to continue . . .

My result of RUN AS with third party explorer :-

D:\_T\D3\Clean30\V\Y\Harmless.bat
C:\WINDOWS\system32
Press any key to continue . . .

I know that my version of Windows Explorer in Windows Home + SP3 has no such problem,
at least no problem today - but who knows what next Patch Tuesday will do ! ! !

Regards
Alan

[avery_larry]

You should never assume the location that a script file is run from. If it's important you should always explicitly specify the current directory.

always.

And then, if it's important (like using del *.exe), you should double check that you're in the correct directory.

[alan_b]

You should never assume the location that a script file is run from. If it's important you should always explicitly specify the current directory.

That assumption has never failed me before because I have never before used RUN AS ...
Please advise me, are there any other situations in which that assumption is false.
Just to cover my posterior I now have a default start of
CD /D %~dp0
but recognize this may cause problems if it is called by a script that first does a "CD /D " to a different folder that needs to be processed.

N.B. The assumption has never failed for me since DOS 3.?,
not even "via RUN AS ..." with Windows Explorer (so far).
Probably many of the people who only register to get help are similarly ignorant.

Could you please create a separate "stickied" topic/item to warn us of all the ways in which this assumption is hazardous.

And then, if it's important (like using del *.exe), you should double check that you're in the correct directory.

I only used "DEL *.EXE" as an example of the extreme danger of using "RUN AS ..." with my preferred third party explorer, and could be present with other third party tools.

In my particular case I normally run the Piriform CCleaner to purge junk on Shutdown by double clicking a desktop shortcut which not only stipulates the path and name of my BAT script, but also has a "Start in ..." entry that stipulates the same path, and my script then alters a default CCleaner.INI file according to %USERNAME% so that when my daughter uses it the main focus is cleaning the Firefox cache in her profile to which I have no access.

Suddenly she complained it failed to work, and I found that a recent change from FAT32 to NTFS of the "Portable Tool" partition H:\ had left her with the special permission to READ and to EXECUTE, but 19 other authorities were lacking, and my script under her authority could no longer modify CCleaner.INI. So I gave all users full access to the Portable Tools - other than things like Minitool Partition Wizard etc - I am not that crazy ! ! !

Then she reported other problems, so to thoroughly debug without needing her password to access her profile and use her restricted access level, I enabled the Guest Account and have focused upon getting the script to run with Guest Account Access level. I then chose to use "RUN AS ..." so I could instantly run/test the script at Guest level and then instantly switch back to Admin status to do whatever it took to get things right.

Whilst "fixing things" I chose not to pollute the desktop with numerous shortcuts to my debug scripts, hence "RUN AS ..." was applied to my selection in explorer. Hence I saw the problem.

All I could see was "Access Denied" and only after adding the command "CD" did I observe that I had not been diverted to the Guest account profile (as I suspected) but to C:\Windows\system32, and that is NOT where CCleaner.INI is held ! ! !
As they say at the end of some films,
"No EXE was injured during the course of this production"

Regards
Alan

[aGerman]

Well Alan, I really thought everybody knows that "RunAs" executes the file in %SystemRoot%\System32. I think the reason why is that runas.exe is placed there and the called batch file / executable inherits the environment from runas.exe. (BTW: The "Run As Administrator" of the right click drop down menu in Win7 works the same way.)

But, have a look at option /env Usually the called file should be executed in the environment from where runas was launched.

Otherwise I think it's a good idea to use something like

Code: Select all

cd /d "%~dp0" ||(echo CD failed&pause&goto :eof)

in your batch file.

Regards
aGerman

[alan_b]

When I write a script that takes action after changing directory I like to have a suitable abort in case the directory does not exist or has access permissions blocked so I accept the wisdom of your suggestion.
I am just wondering why would there be a failure with
cd /d "%~dp0"
Is it possible that the script being executed does not reside at "%~dp0". ?
I am aware that CACLS can display and control access rights, and I think I counted 21 different "special access" possibilities such as Generic_Read and Generic_Execute. Could the script user have permission to execute a script at "%~dp0" and yet be prohibited from cd /d "%~dp0"
Or have I missed something obvious ?

Actually I never even knew RUNAS was an executable I could launch from DOS.

I have only seen and used it from the right click context menu of explorer GUI's, and that gives no such options on XP Home.
I have now launched CMD.EXE and seen the results of invoking RUNAS /?

I have now had a look at system32\run* and was also also surprised to see runonce.exe
I have seen installation/removal scripts that use REG.EXE etc to arrange a one-time-only action on the next reboot.
I guess runonce.exe does something related to this.
I wondered how to use it so I tried
RUNONCE /?
It told me nothing - I hope it has not done something to punish me on my next reboot ! !

Regards
Alan

[aGerman]

I am just wondering why would there be a failure with
cd /d "%~dp0"
Is it possible that the script being executed does not reside at "%~dp0". ?

Run As admin is one thing. I agree this should work anyway.
On the other hand you could make mistakes. Lets say you are user "A" and your batch file is somewhere on your own profile. If you Run As user "B" then cd /d "%~dp0" would fail.
I know this example makes no sense (why using cd /d "%~dp0"), but it's possible ...

I am aware that CACLS can display and control access rights, and I think I counted 21 different "special access" possibilities such as Generic_Read and Generic_Execute.

Well, if you are able to change the working directory to %~dp0 but you have no rights to do anything -- so what... you would realize it without CACLS.

I have now had a look at system32\run* and was also also surprised to see runonce.exe
[...]
I wondered how to use it so I tried
RUNONCE /?
It told me nothing - I hope it has not done something to punish me on my next reboot ! !

Dangerous!!! It will execute the evil question mark!!!
Just kidding. It's harmless

Regards
aGerman