【问题标题】:alternative to xp_cmdshell bcp?xp_cmdshell bcp 的替代品?
【发布时间】:2020-07-30 17:33:04
【问题描述】:

有没有 xp_cmdshell BCP 的替代方法可以从 MSSQL 写入文件?

一些上下文:这将被构建到由外部程序调用的存储过程中。我没有精力处理可执行文件、ssms 的导出函数或任何此类需要调用此存储过程之外的东西。

原因;这台服务器上有很多奇怪的东西与用户权限有关,我不是 SA。我无法创建 ##xp_cmdshell_proxy_account##(更不用说为其分配凭据),并且 xp_cmdshell 'whoami' 返回一个从未见过或听过的用户。我已经尝试根据现有的 Windows 用户创建一个新用户并授予 xp_cmdshell 执行权限,但这仍然没有做任何事情。我不确定是我没有权利还是其他原因。

长话短说,我已经厌倦了试图让它在这种环境下工作,并正在寻找替代方案。有吗?

【问题讨论】:

  • 首先没有理由使用xp_cmdshell。一方面,您可以使用BULK INSERT 导入数据。另一方面,使用 bcp 的常规方法是从批处理文件或 Sql Server 代理作业 - notxp_cmdshell。简单地启用该功能会增加安全漏洞的可能性,或者允许恶意代码使用 SQL Server 服务帐户的权限执行。只是不需要
  • 不需要,因为 20 年没用过了。运行命令或 Powershell 脚本的代理作业,是的。调用 CLI 程序的 SSIS 作业是的,我现在正在为一些复杂的作业执行此操作。
  • there's a lot of odd stuff on this server 奇怪的不是服务器。默认情况下,xp_cmdshell 以及其他敏感功能被禁用。其中一些,如 SQLCLR,需要启用一些高级功能。 xp_cmdshell 和 ActiveX 的存在主要是为了向后兼容,通常启用。

标签: sql-server stored-procedures xp-cmdshell


【解决方案1】:

编写一个 SQL 代理作业并使用 sp_start_job 启动它。您可以使用 SQL Agent Proxy 控制作业使用的身份。

或者编写一个 SSIS 包,将其部署到 SSIS 目录和run it from your stored procedure

【讨论】:

    猜你喜欢
    • 2018-01-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-09-17
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多