Изменения 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.

• Средство перенаправления сети регистрируется с помощью FsRtlRegisterUncProviderEx, новой подпрограммы, которая была введена в Windows Vista.

• Сетевой перенаправитель передает безымянный объект устройства в FsRtlRegisterUncProviderEx.

• Сетевой перенаправитель передает имя устройства в FsRtlRegisterUncProviderEx.

• Сетевой перенаправитель не регистрируется как файловая система в диспетчере ввода-вывода (не вызывает IoRegisterFileSystem).

• Все вызовы из MUP в сетевой перенаправитель, включая разрешение префикса, IOCTLs и FSCTLs, выполняются с включенными APC. Ожидается, что все вызовы из других компонентов в MUP будут осуществлены с включёнными APC. Если вызовы используются с 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. Сетевые мини-перенаправители, которые статически связываются с Windows Vista RDBSS (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 выполняются с включенными APC, что оказывает следующее воздействие:

• Важно, при необходимости, защитить пути кода, которые вызываются из 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 приведены следующим образом:

IOCTL и структуры данных определяются в ntifs.h. Буферы выделяются из пула, не использующего страничную память.

Сетевые перенаправления должны учитывать только отправителей в режиме ядра этого IOCTL, убедившись, что Irp->RequestorModeKernelMode.

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;

Поставщики UNC должны использовать структуру данных QUERY_PATH_RESPONSE для предоставления информации в ответе.

typedef struct _QUERY_PATH_RESPONSE {
 ULONG  LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;

Обратите внимание, что 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 заявит префикс от имени мини-редиректора сети.