A Thousand Things 1% Better

That was the title of a recent blog post by Jeffery Snover on the PowerShell team blog. I recently had the privilege of sitting down with Jeffery Snover and the PowerShell team and just talk about bits and pieces in PowerShell and PrimalScript.

One question I was asked was what I would think the PowerShell team could do to make PowerShell’s acceptance become even faster moving. I am flattered that they thought I had an answer to that, so I’ll give it a shot. And sticking with Jeff’s “A Thousand Things 1% Better” theme, I’ll pick something that can easily be fixed.

One thing, that makes me go to the standard command prompt rather than PowerShell is the ./ requirement for some commands.

Just say I am deep down in some folder, like “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727”
and I want to run regasm against some dll I created.
I have to type ./regasm because my framework folder is not in the path. Which makes me end up ALWAYS typing it twice because I can never remember to type the darn dot slash. The inconsistency of sometimes having to type it and sometimes not makes it impossible to get used to it. Am I in a folder that is in the path? Trial and error every time.

I understand that this dot slash scheme was invented to prevent command injection. So that you cannot substitute an internal command with a potentially malicious external script or executable, you have to fully specify the path name to the file.

But since regasm is no internal command it won’t substitute anything. And since I can put a malicious notepad.cmd anywhere in a folder in the PATH environment and it gets executed instead of the real notepad.exe, the entire command injection prevention fails for me.

The problem here is not with the PowerShell team though. Preventing command injection is a job for the operating system, not for a shell. UNIX systems had a mechanism for decades for  that, called the executable attribute. Any exe, cmd, ps1, bat and whatnot file would be as dead as a doorknob unless that attribute exists. It simply would not run.
Any file system activity, like moving, copying or opening and modifying a file results in this attribute being removed. It takes an admin user with chmod to add that bit again. Simple, effective and elegant.

Microsoft already has a mechanism for that, just try to download a CHM file to your desktop from some website and view it. You will have to right click and unlock it before it works.

So please, PowerShell folks, make it better by making it easier for us to execute commands. Remove the inconsistency and influence the powers at work to add proper command injection protection to the OS. It is not a shell’s job to do that.

Technorati Tags: ,