IOCTL_REDIR_QUERY_PATH_EX IOCTL(ntifs.h)

아티클
10/14/2023

Windows Vista부터 MUP(다중 UNC 공급자)는 네트워크 리렉터에 IOCTL_REDIR_QUERY_PATH_EX 제어 코드를 전송하여 이름 기반 작업에서 특정 UNC 경로(일반적으로 IRP_MJ_CREATE 요청)를 처리할 수 있는 공급자를 결정합니다. 이 요청을 "접두사 확인"이라고 합니다.

MUP는 원격 파일 시스템 요청을 처리할 수 있는 네트워크 리렉터(UNC 공급자)에 UNC 이름을 사용하여 모든 원격 파일 시스템 액세스를 채널링하는 커널 모드 구성 요소입니다. 명령줄에서 실행할 수 있는 다음 예제와 같이 UNC 경로를 사용하는 경우 MUP가 관련됩니다.

notepad \\server\public\readme.txt

MUP는 매핑된 드라이브 문자(예: "NET USE" 명령)를 만드는 작업 중에는 포함되지 않습니다. 이 작업은 MPR(다중 공급자 라우터) 및 네트워크 리렉터에 대한 사용자 모드 WNet 공급자 DLL에 의해 처리됩니다. 그러나 사용자 모드 WNet 공급자 DLL은 이 작업 중에 커널 모드 네트워크 리 디렉터 드라이버와 직접 통신할 수 있습니다.

Windows Vista 리렉터 모델을 준수하는 네트워크 리렉터의 경우 매핑된 네트워크 드라이브를 사용하는 경우에도 MUP가 관련됩니다. 매핑된 드라이브에서 수행되는 파일 작업은 MUP를 통해 네트워크 리렉터로 이동합니다. 이 경우 MUP는 관련 네트워크 리렉터에 작업을 전달하기만 하면 됩니다.

IOCTL_REDIR_QUERY_PATH_EX 제어 코드는 FsRtlRegisterUncProviderEx를 호출하여 MUP에 UNC(범용 명명 규칙) 공급자로 등록된 네트워크 리디렉션기로 전송됩니다. MUP에 등록된 여러 UNC 공급자가 있을 수 있습니다.

접두사 확인 작업은 다음 두 가지 용도로 사용됩니다.

접두사 확인을 초래한 이름 기반 작업은 접두사를 클레임하는 공급자로 라우팅됩니다. 성공하면 MUP는 후속 핸들 기반 작업(예: IRP_MJ_READ 및 IRP_MJ_WRITE)이 동일한 공급자로 MUP를 통과하도록 합니다. 이 동작은 접두사 확인을 위해 IOCTL_REDIR_QUERY_PATH 전송되는 Windows Vista 리디렉션기 모델을 준수하지 않는 네트워크 리렉터에 대해 다릅니다. Windows Vista 리다이렉터 모델을 준수하지 않는 네트워크 리렉터의 경우 MUP는 후속 핸들 기반 작업에 대해 완전히 무시됩니다.
공급자와 클레임한 접두사는 MUP에서 유지 관리하는 접두사 캐시에 입력됩니다. 후속 이름 기반 작업의 경우 MUP는 이 접두사 캐시를 사용하여 MUP가 접두사 확인을 수행하기 전에 공급자가 이미 접두사를 요청했는지 여부를 확인합니다. 이 접두사 캐시의 각 항목은 캐시에 추가되면 시간 제한(TTL이라고 함)이 적용됩니다. 이 시간 제한이 만료되면 항목이 throw되며, 이때 MUP는 후속 이름 기반 작업에서 이 접두사에 대해 접두사 확인을 다시 수행합니다.

주 코드

IOCTL_REDIR_QUERY_PATH_EX

입력 버퍼

IrpSp->Parameters.DeviceIoControl.Type3InputBuffer 는 요청을 포함하는 QUERY_PATH_REQUEST_EX 데이터 구조로 설정됩니다.

입력 버퍼 길이

입력 버퍼가 가리키는 QUERY_PATH_REQUEST_EX 구조체의 크기(바이트)입니다.

출력 버퍼

Irp->UserBuffer 는 응답을 포함하는 QUERY_PATH_RESPONSE 데이터 구조로 설정됩니다.

출력 버퍼 길이

출력 버퍼가 가리키는 QUERY_PATH_RESPONSE 구조체의 크기(바이트)입니다.

입력/출력 버퍼

해당 없음

입력/출력 버퍼 길이

해당 없음

상태 블록

\\server\share 접두사 이름이 인식되면 Status 멤버가 성공 시 STATUS_SUCCESS 또는 다음 중 하나와 같은 적절한 NTSTATUS 값으로 설정됩니다.

상태 코드	의미
STATUS_BAD_NETWORK_NAME	지정된 공유 이름을 원격 서버에서 찾을 수 없습니다. 컴퓨터 이름(예: \\server)은 유효하지만 지정된 공유 이름은 원격 서버에서 찾을 수 없습니다.
STATUS_BAD_NETWORK_PATH	네트워크 경로를 찾을 수 없습니다. 컴퓨터 이름(예: \\server)이 잘못되거나 네트워크 리렉터에서 컴퓨터 이름을 resolve 수 없습니다(사용 가능한 이름 확인 메커니즘 사용).
STATUS_INSUFFICIENT_RESOURCES	버퍼에 메모리를 할당하는 데 사용할 수 있는 리소스가 부족했습니다.
STATUS_INVALID_DEVICE_REQUEST	IOCTL_REDIR_QUERY_PATH_EX 요청은 MUP에서만 제공되며 IRP 구조의 RequestorMode 멤버는 항상 KernelMode여야 합니다. 호출 스레드의 요청자 모드가 KernelMode가 아닌 경우 이 오류 코드가 반환됩니다.
STATUS_INVALID_PARAMETER	QUERY_PATH_REQUEST 구조체의 PathNameLength 멤버가 유니코드 문자열의 최대 허용 길이(UNICODE_STRING_MAX_BYTES)를 초과합니다.
STATUS_LOGON_FAILURE 또는 STATUS_ACCESS_DENIED	잘못된 자격 증명 또는 잘못된 자격 증명으로 인해 접두사 확인 작업이 실패한 경우 공급자는 원격 서버에서 반환한 정확한 오류 코드를 반환해야 합니다. 이러한 오류 코드는 STATUS_BAD_NETWORK_NAME 또는 STATUS_BAD_NETWORK_PATH 변환해서는 안 됩니다. STATUS_LOGON_FAILURE 및 STATUS_ACCESS_DENIED 같은 오류 코드는 사용자에게 피드백 메커니즘 역할을 하며 적절한 자격 증명을 사용해야 하는 요구 사항을 나타냅니다. 이러한 오류 코드는 특정 경우에 사용자에게 자격 증명을 자동으로 요청하는 데도 사용됩니다. 이러한 오류 코드가 없으면 사용자는 컴퓨터에 액세스할 수 없다고 가정할 수 있습니다.

네트워크 리다이렉터에서 접두사를 resolve 수 없는 경우 위의 권장 NTSTATUS 코드 목록에서 의도한 의미 체계와 밀접하게 일치하는 NTSTATUS 코드를 반환해야 합니다. NTSTATUS 코드가 위의 목록에 없는 경우 네트워크 리다이렉터는 실제 발생한 오류(예: STATUS_CONNECTION_REFUSED)를 MUP에 직접 반환해서는 안 됩니다.

설명

네트워크 리디렉터는 Irp-RequestorMode>가 KernelMode인지 확인하여 이 IOCTL의 커널 모드 보낸 사람만 적용해야 합니다.

IOCTL_REDIR_QUERY_PATH_EX METHOD_NEITHER IOCTL입니다. 즉, 입력 및 출력 버퍼가 동일한 주소에 있지 않을 수 있습니다. UNC 공급자의 일반적인 실수는 입력 버퍼와 출력 버퍼가 동일하다고 가정하고 입력 버퍼 포인터를 사용하여 응답을 제공하는 것입니다.

UNC 공급자가 IOCTL_REDIR_QUERY_PATH_EX 요청을 받으면 QUERY_PATH_REQUEST_EX 구조체의 PathName 멤버에 지정된 UNC 경로를 처리할 수 있는지 여부를 결정해야 합니다. 이 경우 UNC 공급자는 클레임한 접두사 길이(바이트)로 QUERY_PATH_RESPONSE 구조체의 LengthAccepted 멤버를 업데이트하고 STATUS_SUCCESS IRP를 완료해야 합니다. 공급자가 지정된 UNC 경로를 처리할 수 없는 경우 적절한 NTSTATUS 오류 코드로 IOCTL_REDIR_QUERY_PATH_EX 요청에 실패해야 하며 QUERY_PATH_RESPONSE 구조체의 LengthAccepted 멤버를 업데이트해서는 안됩니다. 공급자는 어떤 조건에서도 다른 멤버 또는 PathName 멤버를 수정해서는 안 됩니다.

공급자가 주장하는 접두사 길이는 개별 UNC 공급자에 따라 달라집니다. 대부분의 공급자는 일반적으로 \\servername sharename\ 경로 형식의 경로에서 \\servernamesharename\\ 부분을 주장합니다. 예를 들어 공급자가 \\serverpublic\dir1\dir2 경로를 지정하여 \\server\\public을 클레임한 경우 접두사 캐시에 접두사 캐시가 이미 있으므로 접두사 \\serverpublic(예: \\server\\public\file1)에 대한 모든 이름 기반 작업이 접두사 확인 없이 해당 공급자로 자동으로 라우팅됩니다. 그러나 접두사 \\server\마케팅\프레젠테이션 이 있는 경로는 접두사 확인을 거닐게 됩니다.

네트워크 리다이렉터에서 서버 이름(예: \\server)을 클레임하는 경우 이 서버의 공유에 대한 모든 요청은 이 네트워크 리디렉션기로 이동합니다. 이 동작은 동일한 서버의 다른 공유가 다른 네트워크 리디렉터에 의해 액세스될 가능성이 없는 경우에만 허용됩니다. 예를 들어 UNC 경로의 \\server 를 클레임하는 네트워크 리디렉터는 이 서버의 다른 공유에 대한 다른 네트워크 리디렉터의 액세스를 차단합니다(예: \\server\web에 대한 WebDAV 액세스).

자세한 내용은 디자인 가이드의 다음 섹션을 참조하세요.