Does anyone have a good reason to run xp_CmdShell?

Question

Does anyone have a good reason to run xp_CmdShell?

Viewing 3 posts - 106 through 107 (of 107 total)

You must be logged in to reply to this topic. Login to reply

Evil Kraig F SSC Guru Points: 100851 More actions · Answer 1

Jeff Moden (6/26/2011)
They're very useful for things other than xp_CmdShell. A simple example is where you want someone to use a proc that truncates a real table without giving that user ALTER privs on the table itself or maybe something more elemental... the privs to run a proc that updates a table without have privs to even see the table on their own. When you're properly set up, it's childs play to apply certs as the code is being promoted to QA or Production.

I was responding to this and realized the level of derail I was going to cause. Short version: I'll start a thread in a day or two on DBA to Dev relationships and code volume/ownership.

- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA

Evil Kraig F SSC Guru Points: 100851 More actions · Answer 2

As Promised: http://www.sqlservercentral.com/Forums/Topic1132391-391-1.aspx?Update=1

- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA

Jeff Moden SSC Guru Points: 1004302 More actions · Answer 3

Craig Farrell (6/26/2011)
Jeff Moden (6/26/2011)
They're very useful for things other than xp_CmdShell. A simple example is where you want someone to use a proc that truncates a real table without giving that user ALTER privs on the table itself or maybe something more elemental... the privs to run a proc that updates a table without have privs to even see the table on their own. When you're properly set up, it's childs play to apply certs as the code is being promoted to QA or Production.
I was responding to this and realized the level of derail I was going to cause. Short version: I'll start a thread in a day or two on DBA to Dev relationships and code volume/ownership.

I guess I don't understand where you're going with that because the relationship between a DBA and Dev and/or code ownership has nothing to do with whether or not a user has privs to run a proc that TRUNCATEs a table without having ALTER privs on that table.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)