在终端服务会话中访问可移动驱动器

发布于 2024-08-23 02:55:37 字数 1028 浏览 14 评论 0原文

我有一个托盘应用程序,它向 shell 注册,以便在将驱动器添加到系统或将介质插入驱动器时(通过 SHChangeNotifyRegister)接收通知。收到这些通知后,我尝试打开驱动器以从中查询一些属性。在我的测试中,我使用一个简单的 USB 闪存驱动器。当我在物理控制台登录时,这工作正常,但如果我通过远程桌面登录,则 CreateFile 调用将失败并显示 ERROR_ACCESS_DENIED。

我将 CreateFile 调用为:

CreateFile(szDrive, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0 NULL);

其中 szDrive 的格式为 "\\\\.\\G:"。之后,我进行了几次 DeviceIoControl 调用。

奇怪的是,我已经对此运行了进程监视器,并且在远程桌面场景中,我的托盘应用程序的驱动器上没有 CreateFile 的记录。我知道我的托盘应用程序正在调用它,因为我编写了一个日志文件,并且我在进程监视器日志中看到 CreateFile 调用该日志文件。就好像它还没有走得足够远,不足以被进程监视器挂钩。

该机器是Windows 7,具有所有默认设置(即UAC)。我的帐户是本地管理员。在这两种情况(本地和远程桌面)中,我都以标准用户身份运行托盘应用程序(即无提升)。但是,如果我提升托盘应用程序,则远程桌面方案将成功打开驱动器。

这可能最终成为我们不支持的场景,但我仍然想知道这里发生了什么。有什么想法吗?

编辑1:再次查看后,似乎所有驱动器(不仅仅是可移动驱动器)都会发生这种情况。观察到的行为是相同的:CreateFile 失败,并显示 ERROR_ACCESS_DENIED,并且进程监视器中没有日志。

编辑2:看来远程登录被拒绝读取访问;如果我将 GENERIC_READ 替换为 0,则它会成功打开驱动器(尽管 DeviceIoControl 调用因 ERROR_ACCESS_DENIED 而失败)。我正在尝试使用 WinObj 尝试查看是否可以授予对驱动器的远程登录读取访问权限。

I have a tray application that registers with the shell to receive notifications when a drive is added to the system or when media is inserted into a drive (via SHChangeNotifyRegister). Upon receipt of those notifications, I attempt to open the drive to query some properties from it. For my testing I am using a simple USB flash drive. This works fine when I am logged on at the physical console, but if I am logged on via remote desktop then the CreateFile call fails with ERROR_ACCESS_DENIED.

I am calling CreateFile as:

CreateFile(szDrive, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0 NULL);

where szDrive is of the form "\\\\.\\G:". After this I make a couple of DeviceIoControl calls.

The strange thing is that I have run Process Monitor on this and in the remote desktop scenario there are NO records of CreateFile on the drive from my tray application. I know my tray app is calling it because I write a log file and I see the CreateFile calls for the log file in the Process Monitor log. It's like it's not even getting far enough to be hooked by Process Monitor.

The machine is Windows 7 with all the default settings (i.e. UAC). My account is a local administrator. In both scenarios (local and remote desktop) I am running my tray app as standard user (i.e. no elevation). However, if I elevate my tray app then the remote desktop scenario is successful in opening the drive.

This could end up being a scenario that we just won't support, but I would still like to know what's going on here. Any ideas?

EDIT 1: After looking at this again, it seems to happen for ALL drives (not just removable ones). The observed behavior is the same: CreateFile failing with ERROR_ACCESS_DENIED and no logs in Process Monitor.

EDIT 2: It seems the remote logon is being denied read access; if I replace GENERIC_READ with 0 then it successfully opens the drive (though the DeviceIoControl calls fail with ERROR_ACCESS_DENIED). I am playing around with WinObj trying to see if I can give the remote logon read access to the drives.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

尸血腥色 2024-08-30 02:55:37

我相信我已经找到答案了。来自 Microsoft 有关 Vista 中可移动存储设备的白皮书

I/O 管理器和可移动媒体设备 ACL

当驱动程序堆栈创建设备对象时,I/O 管理器会根据设备类型设置默认 ACL。默认 ACL 向系统和管理员授予完全访问权限,而仅向其他人授予执行访问权限。

  • 默认情况下,在 Windows Vista 中,I/O 管理器向 IU 组授予对可移动媒体设备(例如 CD 驱动器)的设备对象以及已定义 FILE_REMOVABLE_MEDIA 特征的磁盘设备对象的完全访问权限。
    注意:在早期版本的 Windows 中,I/O 管理器设置的 ACL 中不存在 IU 条目。 Windows Vista I/O 管理器提供对 IU 组的完全访问权限,以便应用程序可以直接访问卷,而无需提升权限,如前所述。但是,未设置“可移动”属性的 UFD 设备不会从此受益,因为 I/O 管理器不会将它们视为可移动。
  • 如果标识数据(响应 SCSI INQUIRY 命令而从设备接收)设置了可移动属性,则磁盘类驱动程序将设置 FILE_REMOVABLE_MEDIA 特征。由于某些 UFD 设备即使不是真正的可移动介质也会设置此属性,因此 I/O 管理器会将此类设备视为可移动磁盘,并为 IU 组提供对该卷的读写访问权限。
  • 默认情况下,Windows Vista I/O 管理器仅向远程连接用户提供对可移动媒体设备对象(CD 设备)以及设置了 FILE_REMOVABLE_MEDIA 特征的磁盘设备对象的执行访问权限。因此,远程用户无法使用 CD 或 DVD 驱动器刻录数据、执行到光学介质的备份或格式化可移动磁盘。管理员可以设置可移动存储访问组策略来覆盖默认行为。设置此策略后,I/O 管理器将授予远程用户对这些设备的完全访问权限,从而允许读取和写入功能。

因此,Vista 在设备上为交互式用户和远程用户设置不同的 ACL。我想它会是这样的。

I believe I have found the answer. From a Microsoft white paper about removable storage devices in Vista:

I/O Manager and Removable Media Device ACLs

When the driver stack creates the device object, the I/O manager sets a default ACL that is based on the device type. The default ACL gives Full access to SYSTEM and Administrators, and it gives only Execute access to everyone else.

  • By default in Windows Vista, the I/O manager grants the IU group Full access for device objects for removable media devices such as CD drives and for those disk device objects that have defined FILE_REMOVABLE_MEDIA characteristics.
    Note: In earlier versions of Windows, the entry for IU was not present in the ACL that was set by the I/O manager. The Windows Vistas I/O manager provides Full access to the IU group, so that applications can receive direct access to a volume without requiring elevation of privilege, as discussed earlier. However, UFD devices that do not set the Removable property do not benefit from this because the I/O manager does not treat them as removable.
  • The disk class driver sets the FILE_REMOVABLE_MEDIA characteristic if the identity data—received from the device in response to the SCSI INQUIRY command—has the Removable property set. Because some UFD devices set this property even though they are not truly removable media, the I/O manager treats such devices as removable disks and provides the IU group Read and Write access to the volume.
  • By default, the Windows Vista I/O manager gives only Execute access for remotely connected users for removable media device objects (CD devices) and for those disk device objects that have FILE_REMOVABLE_MEDIA characteristics set. Because of this, remote users cannot burn data by using a CD or DVD drive or perform backup to an optical media or format a removable disk. Administrators can set the Removable Storage Access group policy to override the default behavior. When this policy is set, the I/O manager grants Full access to remote user for these devices, allowing read and write capabilities.

So Vista sets ACLs on devices differently for the interactive user vs remote users. I figured it would be something like this.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文