Jeff Moden (6/12/2013)
opc.three (6/12/2013)
As for MS supposedly "coming to their senses with xp_CmdShell" goes, just because you disagree with something, doesn't make it bad. It just makes it bad for you.
It's not about like. It's about empirical knowledge. I have literally logged hundreds, if not into the thousands of hours working with applications built around xp_cmdshell going back to the SQL 7 days. That is not even mentioning DBA solutions. I support an app today that uses ECHO and > to log to a file from T-SQL using xp_cmdshell. What a waste of time.
Anyway, it has been more than enough to learn and experience all the pros and cons of using it. From this I know it's worth steering people away from it. It's simply a shitty tool from a security perspective, an application design perspective, a maintenance perspective, a system stability perspective, from an interface perspective, the list goes on and on.
Me too (hundreds, if not thousands of hours). Fortunately, I've not run into stupidity like using ECHO in the manner you've described. Such stupidity, however, isn't limted to xp_CmdShell. It permeates every facet of code in the wrong hands.
A fair point, could be said of anything though. The goal of any piece of software (and framework) should be to guide developers into good ways of doing things that benefit not only the environment and the people working elbow to elbow with each other, but also those that will eventually come after them in that environment. In my estimation, and from seeing what developers typically produce and have left behind when left to their own devices when using it, xp_cmdshell guides developers into, practically promotes, very poor implementations. This is primarily due to the intrinsic properties of it as a piece of software. For these reasons, I could never, ever, recommend using it, ever, for anything, ever.
As you might guess, I'll continue to disagree about it being a "shitty" tool from a security perspective. You can do just as much damage with SSIS that goes out to scripts or uses WMI blocks.
No you can't Jeff. You can lock an SSIS Package execution into running under a service account that is not comingled with the SQL Server service account. You cannot do that with xp_cmdshell. It's a blunt tool that paints you into a corner, namely a corner of running everything under one account where a sysadmin member gets to potentially elevate and definitely obfuscate their identity. For goodness sake man, you have to see this by now. Just accept it already.
You've apparently had as many bad experiences with crappy developers that use xp_CmdShell as I've had with crappy developers that write scripts for SSIS and the like. You and I have had identical problems, just with different products. I guess that's why that even though I totally disagree with your stance on xp_CmdShell and you totally disagree with my stance on other tools, we haven't actually tried to remove each other's heads... yet. 😀
Security-wise it's awful. Design-wise it's awful. Stability-wise it's awful. It's shitty man, and it ain't that serious to go after your head...unless you meant figuratively to try to win over your mind on the matter. That my friend has become a passive hobby of sorts for me at this point 😉
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato