windows - 来自 Windows 7 应用程序的 SPTI/SCSI 操作

Question

我需要一些有关更新某些 Windows 软件以与非存储 SCSI 设备通信的安全问题的帮助。

原始软件是作为 DLL 为 Windows XP 编写的，并通过 Adaptec 的 ASPI API 与设备通信。 ASPI 实际上没有任何安全性，因此任何用户运行的任何应用程序都可以使用我的 DLL 与这些设备之一通信，一切都运行良好。

我现在正在更新软件以使用 Microsoft 的现代 SPTI(SCSI 直通接口(interface))API 与 Windows 7 一起工作。 XP 下的 SPTI 工作正常，但 Windows 7 具有更严格的安全性，对于普通用户甚至管理员，SPTI 调用会返回一个错误，指示权限不足。如果我使用隐藏的“管理员”帐户登录，我的软件可以在 SPTI 上正常运行，但这不是可接受的部署选项。

以下是我目前研究过的一些备选方案，按照必须重写现有代码的程度从低到高的顺序排列:

• 分离线程并提升其权限以伪装成“管理员”以便它可以与 SPTI 对话。 [我无法使用 LogonUser()/ImpersonateLoggedOnUser()/LoadUserProfile() 使它工作；对 LoadUserProfile() 的调用失败，并且 SPTI 调用也因权限不足错误而失败。]
• 编写具有足够权限与 SPTI 对话的 Windows 服务，然后让我的 DLL 与该服务对话。
• 用户空间 (UMDF) 驱动程序。这将是一次昂贵的重写，我不清楚 UMDF 是否支持访问 SCSI 设备。
• 内核 (KMDF) 驱动程序。应该可行，但重写时间更长、成本更高。

我希望这里的社区可以提供一些智慧/经验/想法，让我的代码在 Windows 7 下与这个 SCSI 设备对话，理想情况下不必重写太多。

Answer 1

我将此作为答案进行投标，因为它太长了，不适合作为评论。

我假设您已经尝试设置应用程序的 list ，以便它在运行时需要提升？请务必注意，您必须提升进程，据我所知，您不能提升线程。

您建议将其作为一项服务运行然后与之通信(命名管道或 WCF 是可行的选择)是一个很好的建议。如果您以 Local System 运行它那么您的服务将比本地管理员更有特权。