Поделиться через

Изменения 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 выполнит утверждение префикса от имени мини-перенаправления сети.