Изменения MUP в Microsoft Windows Vista
Windows Vista реализует ряд изменений в нескольких поставщиках UNC (MUP), которые могут повлиять на перенаправители сети.
MUP и клиент распределенной файловой системы (DFS) находятся в отдельных двоичных файлах. Компонент MUP находится в mup.sys, а клиент DFS находится в dfsc.sys. В Windows Server 2003, Windows XP и Windows 2000 компонент ядра MUP, mup.sys, также содержал клиент DFS.
В Windows Vista определена новая модель перенаправителя:
MUP регистрируется в качестве файловой системы в диспетчере ввода-вывода путем вызова IoRegisterFileSystem.
Сетевой перенаправитель регистрируется в MUP с помощью FsRtlRegisterUncProviderEx , новой процедуры, представленной в Windows Vista.
Перенаправитель сети передает неименованный объект устройства в FsRtlRegisterUncProviderEx.
Перенаправитель сети передает имя устройства в FsRtlRegisterUncProviderEx.
Сетевой перенаправитель не регистрируется в качестве файловой системы в диспетчере ввода-вывода (не вызывает IoRegisterFileSystem).
Все вызовы из MUP к перенаправителю сети, включая разрешение префиксов, ioCTL и FSCTL, выполняются с включенными apcs. Ожидается, что все вызовы из других компонентов в MUP будут выполняться с включенными apcs. Если вызовы используются с FsRtlCancellableWaitForSingleObject или FsRtlCancellableWaitForMultipleObjects, новыми подпрограммами, представленными в Windows Vista, это гарантирует, что длительные ожидания могут быть прерваны, если поток, выдавший запрос ввода-вывода, будет прерван.
Разрешение префиксов выполняется с помощью IOCTL_REDIR_QUERY_PATH_EX , нового IOCTL, появилось в Windows Vista.
Имя устройства перенаправителя сети, зарегистрированное в MUP, становится символьной ссылкой на объект устройства MUP.
Для сетевого перенаправления, соответствующего модели перенаправителя Windows Vista, MUP создает символьную ссылку в пространстве имен диспетчера объектов с именем устройства, указанным сетевым перенаправлением в вызове FsRtlRegisterUncProviderEx. Целью этой символьной ссылки является объект устройства MUP (\Device\Mup).
Преимущество регистрации MUP в качестве файловой системы и имя устройства перенаправления сети, являющееся символьной ссылкой на объект устройства MUP, заключается в том, что все операции ввода-вывода удаленной файловой системы, а не только на основе имен, проходят через MUP. Таким образом, драйверы фильтров файловой системы, которые должны находиться в удаленном стеке файловой системы, могут просто подключиться к объекту устройства MUP. Драйверам фильтров файловой системы больше не нужно жестко задавать имена объектов устройств поставщика (например, \Device\LanmanRedirector) в их драйвере. Таким образом, драйверы фильтров файловой системы могут отслеживать все операции ввода-вывода, выданные всем сетевым перенаправлениям с помощью одного вложения. Это также исключает дублирование операций ввода-вывода, наблюдаемых драйверами фильтров файловой системы до Windows Vista, которые подключаются отдельно к DFS (mup.sys) и отдельным сетевым перенаправлениям (например,\Device\LanmanRedirector), чтобы отслеживать операции ввода-вывода для обоих.
Драйвер фильтра файловой системы, подключенный к объекту устройства MUP, может выборочно фильтровать трафик, отправляемый определенным сетевым перенаправителям. В этом случае драйвер фильтра сопоставляет имена устройств сетевых перенаправителей с идентификаторами поставщиков путем вызова подпрограммы FsRtlMupGetProviderIdFromName . Затем драйвер фильтра может определить, следует ли фильтровать трафик для определенного объекта файла, сравнив идентификатор поставщика, полученный путем вызова подпрограммы FsRtlMupGetProviderInfoFromFileObject с идентификаторами поставщиков заинтересованных сетевых директоров.
Для сетевого перенаправления, соответствующего модели перенаправителя Windows Vista:
Все объекты файлов в стеке удаленной файловой системы разрешаются в MUP. Таким образом, IoGetDeviceAttachmentBaseRef возвращает объект устройства для MUP, а не сетевой перенаправитель, которому принадлежит объект файла. Однако содержимое объекта файла по-прежнему принадлежит сетевому перенаправлению.
IRP_MJ_CREATE, выдаваемый на имя устройства сетевого перенаправителя (например,\Device\LanmanRedirector\server\share), будет предназначен для этого перенаправителя сети без разрешения префикса MUP, точно так же, как в Windows Server 2003, Windows XP и Windows 2000.
Сетевые перенаправления, не основанные на RDBSS Windows Vista (динамическое или статическое связывание), называются устаревшими перенаправлениями. К этим устаревшим сетевым перенаправлениям относятся:
Сетевые перенаправления, написанные для Windows Server 2003, Windows XP и Windows 2000, которые регистрируются непосредственно в MUP с помощью FsRtlRegisterUncProvider.
Сетевые мини-перенаправления, написанные для Windows Server 2003, Windows XP и Windows 2000, которые статически связываются с библиотекой rdbsslib.lib для Windows Server 2003, Windows XP или Windows 2000.
Сетевые перенаправления, написанные для Windows Vista, которые регистрируются непосредственно в MUP с помощью FsRtlRegisterUncProviderEx.
Сетевые мини-перенаправления, которые динамически связываются с windows Vista RDBSS (rdbss.sys), автоматически соответствуют модели перенаправителя Windows Vista, так как RDBSS регистрируется в MUP с помощью FsRtlRegisterUncProviderEx. Сетевые мини-перенаправления, которые статически связываются с RDBSS Windows Vista (rdbsslib.lib), также автоматически соответствуют модели перенаправителя Windows Vista, так как RDBSS регистрируется в MUP с помощью FsRtlRegisterUncProviderEx.
Устаревший перенаправитель сети, написанный для Windows Vista, который регистрируется непосредственно в MUP, должен соответствовать модели перенаправителя Windows Vista.
Сетевые перенаправления, написанные для Windows Server 2003, Windows XP и Windows 2000, которые регистрируются в MUP непосредственно с помощью FsRtlRegisterUncProvider , работают точно так же, как и в Windows Server 2003, Windows XP и Windows 2000. Сетевые мини-перенаправления, написанные для Windows Server 2003, Windows XP и Windows 2000, которые статически связываются с библиотекой rdbsslib.lib для Windows Server 2003, Windows XP и Windows 2000, продолжают работать точно так же, как и в Windows Server 2003, Windows XP и Windows 2000. Эти устаревшие сетевые перенаправления и мини-перенаправления демонстрируют следующее поведение:
Они будут видны драйверам фильтров файловой системы, которые отслеживают регистрацию файловой системы.
Их объекты устройств имеют имена. Имена устройств не являются символическими ссылками и не указывают на \Device\MUP.
Объекты файлов разрешаются в именованный объект устройства сетевого перенаправителя.
MUP участвует только в операции разрешения префиксов. После определения поставщика сети MUP "выходит из пути", возвращая STATUS_REPARSE. Все последующие операции не будут проходить через MUP.
Это поведение было сохранено, чтобы предотвратить двойную фильтрацию, которая в противном случае произошла бы, если имя устройства поставщика было символьной ссылкой на \Device\MUP. Эта двойная фильтрация будет происходить по следующим причинам:
Драйвер фильтра файловой системы уже подключен к \Device\MUP.
Драйвер фильтра файловой системы подключается к любой регистрируемой файловой системе. Так как сетевые перенаправители, использующие именованные объекты устройств, регистрируются как файловые системы, драйвер фильтра файловой системы будет фильтровать один и тот же ввод-вывод дважды.
Вызовы MUP в Windows Vista выполняются с включенными apcs, что имеет следующие последствия:
При необходимости важно защитить пути кода, вызываемые из MUP, от приостановки потока соответствующими средствами, особенно IOCTL_REDIR_QUERY_PATH обработчиками. Обратите внимание, что приостановка потока — это операция "неограниченного ожидания", которая может длиться долго.
Важно убедиться, что любая операция "ожидание ввода-вывода", включающая потоки пользовательского режима (в отличие от системных потоков), всегда использует "отменяемые ожидания". Дополнительные сведения см. в подпрограммах FsRtlCancellableWaitForSingleObject и FsRtlCancellableWaitForMultipleObjects .
Взаимоблокировки могут возникать, когда поток приостанавливается, удерживая некоторую важную блокировку. Важно выполнять тесты при наличии произвольной приостановки потоков пользовательского режима, чтобы проверка для условий взаимоблокировки.
Важно выполнить тесты, чтобы убедиться, что "ожидание операций ввода-вывода" действительно можно отменить и что приложение в пользовательском режиме может завершить поток достаточно быстро, чтобы приложение не было в состоянии "не отвечать" при попытке завершить этот поток.
Размер кэша префиксов и время ожидания, используемые MUP в Windows Vista, теперь управляются следующими значениями реестра:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Эти значения реестра можно изменять динамически без перезагрузки. Эти значения реестра находятся в следующем разделе реестра:
HKLM\System\CurrentControlSet\Services\Mup\Parameters.
Значение реестра ProviderOrder, определяющее порядок, в котором MUP выдает запросы разрешения префиксов к отдельным перенаправителям, можно динамически изменять без перезагрузки системы. Это значение реестра находится в следующем разделе реестра:
HKLM\CurrentControlSet\Control\NetworkProvider\Order
В Windows Vista MUP выполняет разрешение префиксов по-разному в зависимости от того, зарегистрирован ли перенаправление сети с помощью MUP путем вызова FsRtlRegisterUncProvider или FsRtlRegisterUncProviderEx. Устаревшие сетевые перенаправления, которые регистрируются в MUP путем вызова FsRtlRegisterUncProvider , получат IOCTL_REDIR_QUERY_PATH запрос на разрешение префиксов. Это тот же метод, который используется в Windows Server 2003, Windows XP и Windows 2000.
Сетевые перенаправления, которые соответствуют модели перенаправителя Windows Vista и регистрируются в MUP путем вызова FsRtlRegisterUncProviderEx , получат IOCTL_REDIR_QUERY_PATH_EX запрос на разрешение префиксов. Обратите внимание, что в Windows Vista сетевые мини-перенаправления, статически связанные с rdbsslib.lib или динамически связанные с rdbss.sys будут вызывать FsRtlRegisterUncProviderEx косвенно через RDBSS.
Входной и выходной буферы для IOCTL_REDIR_QUERY_PATH_EX:
| Параметр доступен в | Формат структуры данных | |
Входной буфер |
IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Выходной буфер |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
IOCTL и структуры данных определяются в файле ntifs.h. Буферы выделяются из нестраничного пула.
Сетевые перенаправления должны учитывать только отправителей режима ядра для этого IOCTL, проверяя, что Irp-RequestorMode> имеет значение KernelMode.
MUP использует структуру данных QUERY_PATH_REQUEST_EX для сведений о запросе.
typedef struct _QUERY_PATH_REQUEST_EX {
PIO_SECURITY_CONTEXT pSecurityContext;
ULONG EaLength;
PVOID pEaBuffer;
UNICODE_STRING PathName;
} QUERY_PATH_REQUEST_EX, *PQUERY_PATH_REQUEST_EX;
| Элемент структуры | Описание |
|---|---|
pSecurityContext |
Указатель на контекст безопасности. |
EaLength |
Длина буфера расширенных атрибутов в байтах. |
pEaBuffer |
Указатель на буфер расширенных атрибутов. |
PathName |
Строка Юникода, не заканчивающаяся значением NULL, для пути к> общей папке><сервера><формы<. |
Поставщики UNC должны использовать структуру данных QUERY_PATH_RESPONSE для получения сведений об ответе.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
| Элемент структуры | Описание |
|---|---|
LengthAccepted |
Длина в байтах префикса, затребованного поставщиком из пути строки Юникода, указанного в элементе PathName структуры QUERY_PATH_REQUEST_EX. |
Обратите внимание, что IOCTL_REDIR_QUERY_PATH_EX является METHOD_NEITHER IOCTL. Это означает, что входные и выходные буферы могут находиться не по одному адресу. Распространенной ошибкой поставщиков UNC является предположение, что входной и выходной буфер совпадают, и использовать указатель входного буфера для предоставления ответа.
Когда поставщик UNC получает запрос IOCTL_REDIR_QUERY_PATH_EX, он должен определить, может ли он обрабатывать UNC-путь, указанный в элементе PathName структуры QUERY_PATH_REQUEST_EX. В этом случае поставщик UNC должен обновить элемент LengthAccepted структуры QUERY_PATH_RESPONSE длиной в байтах запрошенного префикса и завершить IRP STATUS_SUCCESS. Если поставщик не может обработать указанный UNC-путь, он должен завершить запрос IOCTL_REDIR_QUERY_PATH_EX с соответствующим кодом ошибки NTSTATUS и не должен обновлять элемент LengthAccepted структуры QUERY_PATH_RESPONSE. Поставщики не должны изменять другие элементы или строку PathName ни при каких условиях.
В Windows Vista мини-перенаправитель сети, основанный на использовании RDBSS, который указывает на поддержку в качестве поставщика UNC, получит это утверждение префикса, как если бы это было обычное создание подключения дерева, аналогично вызову Createfile в пользовательском режиме с установленным флагом FILE_CREATE_TREE_CONNECTION. RDBSS отправит запрос MRxCreateSrvCall мини-перенаправлению сети, за которым следует вызов MRxSrvCallWinnerNotify и MRxCreateVNetRoot. Это утверждение префикса не будет получено в качестве вызова метода MRxLowIOSubmit[LOWIO_OP_IOCTL]. Когда сетевой мини-перенаправитель регистрируется в RDBSS, таблица диспетчеризации драйверов для сетевого мини-перенаправления будет скопирована RDBSS для указания на внутренние точки входа RDBSS. Затем RDBSS получает этот IOCTL_REDIR_QUERY_PATH_EX для мини-перенаправления сети и вызывает MRxCreateSrvCall, MRxSrvCallWinnerNotify и MRxCreateVNetRoot. Исходная IOCTL_REDIR_QUERY_PATH_EX IRP будет содержаться в RX_CONTEXT, переданной в подпрограмму MRxCreateSrvCall . Кроме того, будут изменены следующие элементы в RX_CONTEXT, переданные в MRxCreateSrvCall :
Для элемента MajorFunction задано значение IRP_MJ_CREATE несмотря на то, что исходная IRP была IRP_MJ_DEVICE_CONTROL.
Для элемента PrefixClaim.SuppliedPathName.Buffer задается элемент PathName.Buffer структуры QUERY_PATH_REQUEST_EX.
Для элемента PrefixClaim.SuppliedPathName.Length задается элемент PathName.Length структуры QUERY_PATH_REQUEST_EX.
Элемент Create.ThisIsATreeConnectOpen имеет значение TRUE.
Для элемента Create.ThisIsAPrefixClaim задано значение TRUE.
Для элемента Create.NtCreateParameters.SecurityContext задается элемент SecurityContext структуры QUERY_PATH_REQUEST_EX.
Для элемента Create.EaBuffer задается элемент pEaBuffer структуры QUERY_PATH_REQUEST_EX.
Для элемента Create.EaLength задается элемент EaLength структуры QUERY_PATH_REQUEST_EX.
Элемент Create.Flags будет иметь RX_CONTEXT_CREATE_FLAG_UNC_NAME бит.
Если мини-перенаправитель сети хочет просмотреть сведения о утверждении префикса, он может считывать эти элементы в структуре RX_CONTEXT, передаваемой в MRxCreateSrvCall. В противном случае он может просто попытаться подключиться к общей папке сервера и вернуть STATUS_SUCCESS, если вызов MRxCreateSrvCall был успешным. RDBSS выполнит утверждение префикса от имени мини-перенаправления сети.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по