IOCTL_REDIR_QUERY_PATH IOCTL(ntifs.h)

아티클
10/14/2023

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

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

notepad \\server\public\readme.txt

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

Windows Server 2003, Windows XP 및 Windows 2000에서는 DFS(분산 파일 시스템) 드라이브를 나타내지 않는 매핑된 드라이브에서 수행되는 원격 파일 작업은 MUP를 거치지 않습니다. 이러한 작업은 드라이브 문자 매핑을 처리한 네트워크 공급자로 직접 이동합니다.

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

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

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

접두사 확인을 초래한 이름 기반 작업은 접두사를 주장하는 공급자로 라우팅됩니다. 성공하면 MUP는 후속 핸들 기반 작업(예: IRP_MJ_READ 및 IRP_MJ_WRITE)이 MUP를 완전히 우회하는 동일한 공급자로 이동하도록 합니다.
공급자 및 클레임한 접두사는 MUP에서 유지 관리되는 접두사 캐시에 입력됩니다. 후속 이름 기반 작업의 경우 MUP는 이 접두사 캐시를 사용하여 MUP에서 접두사 확인을 수행하기 전에 공급자가 이미 접두사를 요청했는지 여부를 확인합니다. 이 접두사 캐시의 각 항목은 캐시에 추가되면 시간 제한(TTL이라고 함)이 적용됩니다. 이 시간 제한이 만료되면 항목이 throw되며, 이 시점에서 MUP는 후속 이름 기반 작업에서 이 접두사에 대해 접두사 확인을 다시 수행합니다.

주 코드

IOCTL_REDIR_QUERY_PATH

입력 버퍼

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

입력 버퍼 길이

적어도 이어야 하는 입력 버퍼의 길이(바이트)입니다 sizeof(QUERY_PATH_REQUEST).

출력 버퍼

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

출력 버퍼 길이

출력 버퍼의 길이(바이트) 이상 sizeof(QUERY_PATH_RESPONSE)이어야 합니다.

입력/출력 버퍼

해당 없음

입력/출력 버퍼 길이

해당 없음

상태 블록

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

상태 코드	의미
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 METHOD_NEITHER IOCTL입니다. 즉, 입력 및 출력 버퍼가 동일한 주소에 있지 않을 수 있습니다. UNC 공급자의 일반적인 실수는 입력 버퍼와 출력 버퍼가 동일하다고 가정하고 입력 버퍼 포인터를 사용하여 응답을 제공하는 것입니다.

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

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

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

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