Contents:
- 1 Kernel Object 란?
- 2 A Process's Kernel Object Handle Table
- 2.1 Creating a kernel Object
- 2.2 Closing a Kernel Object
2 A Process's Kernel Object Handle Table #
커널 오브젝트 핸들 테이블은 시스템에 의하여 생성되고 초기화 되며 각 프로세스에 하나의 핸들 테이블이 존재한다. 핸들 테이블에 대한 자세한 것은 문서화되어 있지 않지만 대략 다음과 같은 구조로 구성되어 있다.
<표 1> 프로세스의 핸들 테이블 구조
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0x???????? | 0x???????? | 0x???????? |
| 2 | 0x???????? | 0x???????? | 0x???????? |
| ... | ... | ... | ... |
2.1 Creating a kernel Object #
핸들 테이블은 프로세스에 의하여 초기화 될 때 비어 있지만 새로운 커널 오브젝트가 생성될 때 마다 비어 있는 곳을 찾아서 초기화 한다.
예 1> 커널 오브젝트를 생성하는 함수
- CreateThread()
- CreateFile()
- CreateMutex()
- CreateSemaphore()
- CreateEvent()
- 그 밖에 ...
커널 오브젝트를 생성하는 모든 함수들은 핸들과 관련된 값을 반환한다. 그러나 이들 핸들 값은 실제 핸들이 아니며 핸들 테이블의 인덱스를 말한다. Windows 2000 의 경우 인덱스 값이라고 하기보다 핸들 테이블의 Byte 수로 구분하기 위하여 반환하는 값이다.
또한 잘못된 핸들을 사용할 경우 핸들을 사용하는 함수들은 실패하며 GetLastError() 함수는 ERROR_INVALID_HANDLE (6) 에러를 리턴한다.
커널 오브젝트를 생성하는 함수들이 실패할 경우 일반적으로 NULL (0) 값을 리턴한다. 하지만 일부 함수의 경우 INVALID_HANDLE_VALUE (-1) 값을 리턴하므로 주의해야 한다.
예 2-1> INVALID_HANDLE_VALUE 값을 리턴하는 함수
HANDLE hMutex = CreateMutex( ... );
if( hMutex == INVALID_HANDLE_VALUE ) {
// We will never execute this code because
// CreateMutex returns NULL if it fails.
}
예 2-2> NULL 값을 리턴하는 함수
HANDLE hFile = CreateFile( ... );
if( hFile == NULL ) {
// We will never execute this code because CreateFile
// returns INVALID_HANDLE_VALUE(-1) if it fails.
}
2.2 Closing a Kernel Object #
모든 커널 오브젝트는 CloseHandle() 함수로 핸들을 닫는다.
BOOL CloseHandle( HANDLE hobj );
이 함수는 먼저 접근 가능한 커널 오브젝트인지 확인 후 커널 오브젝트의 데이타에서 usage count 를 1 감소 시킨다. 그리고 이 값이 0 일 경우 커널 오브젝트를 메모리에서 제거한다.
하지만 잘못된 핸들을 전달할 경우 CloseHandle() 함수는 FALSE 값을 반환하고 GetLastError() 함수는 ERROR_INVALID_HANDLE (6) 값을 반환하게 된다.
그리고 커널 오브젝트의 핸들을 닫지 않고 프로세스가 종료할 경우 메모리 누수에 대하여 우려할 필요없다. 프로세스가 종료할 경우 시스템이 자동적으로 핸들 테이블을 검색하여 핸들을 닫는 과정을 수행한다.
3 Sharing Kernel Objects Across Process Boundaries #
서로 다른 프로세스 사이에서 커널 오브젝트를 공유해야 하는 경우가 많다. 이런 경우 다음과 같은 커널 오브젝트가 사용된다.
- File-mapping objects 는 하나의 컴퓨터에서 다른 프로세스 간에 데이타 블럭을 공유하는 것을 허용하다.
- Mailslots 과 Named pipes 는 서로 다른 컴퓨터 간에 프로세스 사이에서 데이타 블럭을 공유하는 것을 허용한다.
- Mutexs 와 Semaphores, Events 는 서로 다른 프로세스간에 동기화에 사용되며 이 경우 다른 프로그램에게 작업이 완료되었음을 알기 위해 사용되기도 한다.
커널 오브젝트 핸들은 프로세스와 관련되어 있으므로 복잡할 수 있다. 하지만 커널 오브젝트 핸들을 안전하고 튼튼하게 ( robustness ) 관리하기 위해서 이와 같이 처리된다. 만약 커널 오브젝트 핸들을 시스템 전역 값으로 관리될 경우 어떠한 프로세스라도 손쉽게 핸들을 획들할 수 있다. 그리고 보안상의 안전을 위하여 이와 같이 처리된다. 커널 오브젝트는 생성시 접근 권한을 지정할 수 있으며 프로세스에서 접근하기 전에 접근권한을 확인을 요구하기 때문이다.
3.1 Object Handle Inheritance #
오브젝트 핸들 상속은 부모-자식 관계를 갖는 프로세스 사이에서만 가능하다. 커널 오브젝트 핸들을 자식 프로세스를 생성할 때 부모 프로세스에서 상속여부를 결정할 수 있다. 이러한 결정은 여러가지 과정이 필요하다.
첫번째, 부모 프로세스에서 커널 오브젝트를 생성할 때 오브젝트 핸들 상속이 가능하도록 지정해 주어야 한다. 하지만 커널 오브젝트를 상속하는 것이 아니며 커널 오브젝트 핸들만을 상속하도록 지정될뿐이다.
커널 오브젝트 핸들 상속은 부모 프로세스에서 SECURITY_ATTRIBUTES 구조체를 할당한 후 초기화 하여 Create* 함수로 전달한다. 다음 예제는 Mutex 오브젝트를 상속 가능하도록 생성 한다.
SECURITY_ATTRIBUTES sa;
sa.nLength = sizeof( sa );
sa.lpSecurityDescriptor = NULL;
sa.bInheritHandle = TRUE; // Make the returned handle inheritable.
HANDLE hMutex = CreateMutex( &sa, FALSE, NULL );
...
이 예제에서는 기본 보안 설정으로 사용하며 상속가능하도록 SECURITY_ATTRIBUTES 구조체를 초기화 하였다.
주의> Windows 98 에서는 보안 설정이 무시된다.
프로세스 핸들 테이블에는 핸들 상속을 설정할 수 있도록 각 핸들에 대하여 플래그에 상속 설정 비트를 갖고 있다. PSECURITY_ATTRIBUTES 인수에 NULL 값을 전달하여 커널 오브젝트를 생성할 경우 상속이 불가능한 핸들을 반환하며 플래그의 상속 비트 또한 0 으로 설정된다. 즉, bInheritHandle 을 TRUE 값으로 설정할 경우 플래그의 상속 비트가 1 로 설정된다.
프로세스 핸들 테이블에 다음과 같이 2 개의 핸들이 있다고 가정할 경우
<표 2> 2 개의 유효한 핸들을 갖고 있는 프로세스 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0xF0000000 | 0x???????? | 0x00000000 |
| 2 | 0x00000000 | (N/A) | (N/A) |
| 3 | 0xF0000010 | 0x???????? | 0x00000001 |
<표 2> 의 2개의 핸들 ( 핸들 1 과 3 ) 중에서 핸들 1 은 상속할 수 없으며 핸들 3 은 상속 가능하다.
두번째, 상속된 핸들을 사용할 자식 프로세스를 생성해야 한다. CreateProcess() 함수를 이용하여 이 과정을 수행한다.
BOOL CreateProcess(
PCTSTR pszApplicationName,
PTSTR pszCommandLine,
PSECURITY_ATTRIBUTES psaProcess,
PSECURITY_ATTRIBUTES pszThread,
BOOL bInheritHandles,
DWORD dwCreationFlags,
PVOID pvEnvironment,
PCTSTR pszCurrentDirectory,
LPSTARTUPINFO pStartupInfo,
PPROCESS_INFORMATION pProcessInformation
);
이 함수의 여러개의 인수 중에서 bInheritHandles 인수에 대하여 주목해야 한다. 프로세스를 생성할 때 일반적으로 FALSE 값을 전달한다. 이 값은 부모 프로세스 핸들 테이블의 핸들 상속을 자식 프로세스에게 할 수 없도록 시스템에 알려준다.
그러나 이 인수를 TRUE 값으로 전달하게 되면 부모의 상속가능한 핸들을 자식 프로세스에게 상속하게 된다. 자식 프로세스가 생성될 때 다른 프로세스와 마찬가지로 프로세스 핸들 테이블이 만들어지고 초기화 되지만 bInheritHandles 인수를 TRUE 값으로 전달하게 되면 부모 프로세스의 핸들 테이블에서 상속가능한 핸들을 부모 프로세스 핸들 테이블과 똑같은 위치에 복사하게 된다.
그리고 핸들 테이블을 복사할 때 시스템에서는 커널 오브젝트의 usage count 를 1 증가하게 된다. 두 개의 프로세스가 커널 오브젝트를 사용하기 때문에 usage count 가 증가하게 되는 것이다. 따라서 두 개의 프로세스가 모두 CloseHandle() 함수를 호출할 경우 커널 오브젝트가 제거된다.
<표 3> 은 자식 프로세스가 실행되기 전의 프로세스 핸들 테이블로 핸들 3 만 사용가능하다. 이것은 부모 프로세스의 상속가능한 핸들만 복사되었기 때문이다. 만약 자식 프로세스에서 또 다른 자식 프로세스 ( 부모 프로세스의 손자 프로세스 ) 를 생성한다면 똑같은 핸들 테이블을 복사하게 되며 커널 오브젝트의 usage count 도 증가하게 된다.
<표 3> 부모 프로세스로 부터 상속가능한 핸들을 상속한 자식 프로세스의 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0x00000000 | (N/A) | (N/A) |
| 2 | 0x00000000 | (N/A) | (N/A) |
| 3 | 0xF0000010 | 0x???????? | 0x00000001 |
핸들 상속은 자식 프로세스가 생성될 때만 적용되는 것으로 자식 프로세스가 생성된 후 상속가능한 새로운 커널 오브젝트를 생성할 경우 자식 프로세스에게는 상속되지 않는다.
자식 프로세스에게 핸들 상속을 한 경우, 어떤 핸들이 상속되었는지를 자식 프로세스에게 알려주어야 한다.
가장 일반적인 방법으로 Command-line 을 이용하여 자식 프로세스에 전달하는 것이다 ( sscanf() 함수 이용 ). 그리고 IPC 를 이용하는 방법도 있다 ( WaitForInputIdle() 함수 이용 ). 또 다른 방법으로 환경 변수를 이용하는 것으로 부모 프로세스의 환경변수를 자식 프로세스에서 단순히 GetEnvironmentVariable() 함수를 호출하는 것으로 접근할 수 있다. 환경 변수는 자식 프로세스에게 상속되므로 좋은 방법이라고 할 수 있다.
3.2 Changing a Handle's Flags #
간혹, 2 개의 자식 프로세스 중에서 하나의 자식 프로세스에게만 핸들 상속이 필요한 경우가 있을 것이다. 즉, 이런 경우 커널 오브젝트 핸들의 상속을 제어하기 위하여 커널 오브젝트 핸들의 상속 플래그를 변경해야 한다. 이런 경우 SetHandleInformation() 함수를 호출하여 처리한다.
BOOL SetHandleInformation(
HANDLE hObject,
DWORD dwMask,
DWORD dwFlags
);
이 함수는 3 개의 인수를 가지고 있으며 첫번째 hObject 인수는 오브젝트 핸들 값이고, 두번째 dwMask 인수는 변경하기를 원하는 플래그 값이다. 이 플래그 값은 다음과 같다.
#define HANDLE_FLAG_INHERIT 0x00000001
#define HANDLE_FLAG_PROTECT_FROM_CLOSE 0x00000002
두 플래그는 OR 연산으로 같이 사용할 수 있으며, SetHandleInformation() 함수의 세번째 dwFlags 인수는 설정해야할 플래그 값을 지정한다. 예를 들어 커널 오브젝트 핸들의 상속을 허용할 경우 다음과 같다.
SetHandleInformation( hobj, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT );
상속을 허용하지 않을 경우
SetHandleInformation( hobj, HANDLE_FLAG_INHERIT, 0 );
HANDLE_FLAG_PROTECT_FROM_CLOSE 플래그는 핸들을 닫을 수 없도록 시스템에게 알린다.
SetHandleInformation( hobj, HANDLE_FLAG_PROTECT_FROM_CLOSE,
HANDLE_FLAG_PROTECT_FROM_CLOSE );
CloseHandle( hobj ); // Exception is raised
닫을 수 없도록 지정된 핸들을 닫을 경우 CloseHandle() 함수는 예외를 발생 시킨다. 하지만 간혹 핸들을 닫지 못하도록 해야할 경우가 있다. 만약 손자 프로세스까지 상속 되어야 할 핸들을 자식 프로세스에서 손자 프로세스가 생성되기 전에 닫게 되면 상속되지 않으므로 핸들을 닫을 수 없도록 지정해 주어야 한다.
그러나 자식 프로세스에서 HANDLE_FLAG_PROTECT_FROM_CLOSE 플래그를 해제하고 SetHandleInformation() 함수를 호출하게 되면 핸들을 닫을 수 있다.
SetHandleInformation( hobj, HANDLE_FLAG_PROTECT_FROM_CLOSE, 0 );
CloseHandle( hobj );
이러한 플래그의 변경을 GetHandleInformation() 함수를 통하여 확인할 수 있다.
BOOL GetHandleInformation(
HANDLE hObj,
PDWORD pdwFlags
);
이 함수는 지정된 핸들에 대한 현재 플래그 값을 반환한다. 예를 들어 핸들의 상속 여부를 다음과 같이 확인할 수 있다.
DWORD dwFlags;
GetHandleInformation( hObj, &dwFlags );
BOOL fHandleIsInheritable = ( 0 != ( dwFlags & HANDLE_FLAG_INHERIT ) );
프로세스 간에 커널 오브젝트를 공유하기 위한 두번째 방법으로 Named 오브젝트를 사용하는 것이다. 많은 수의 커널 오브젝트는 Name 을 사용할 수 있다. 다음과 같은 커널 오브젝트 생성 함수들은 Named 커널 오브젝트를 생성할 수 있다.
HANDLE CreateMutex(
PSECURITY_ATTRIBUTES psa,
BOOL bInitialOwner,
PCTSTR pszName
);
HANDLE CreateEvent(
PSECURITY_ATTRIBUTES psa,
BOOL bManualReset,
BOOL bInitialState,
PCTSTR pszName
);
HANDLE CreateSemaphore(
PSECURITY_ATTRIBUTES psa,
LONG lInitialCount,
LONG lMaximumCount,
PCTSTR pszName
);
HANDLE CreateWaitableTimer(
PSECURITY_ATTRIBUTES psa,
BOOL bManualReset,
PCTSTR pszName
);
HANDLE CreateFileMapping(
HANDLE hFile,
PSECURITY_ATTRIBUTES psa,
DWORD flProtect,
DWORD dwMaximumSizeHigh,
DWORD dwMaximumSizeLow,
PCTSTR pszName
);
HANDLE CreateJobObject(
PSECURITY_ATTRIBUTES psa,
PCTSTR pszName
);
이 함수들은 공통적으로 마지막 인수로 pszName 을 갖고 있다. 이 인수를 NULL 값으로 전달하게 되면 Unnamed ( Anonymous ) 커널 오브젝트를 생성하게 된다. Unnamed 오브젝트를 생성한 경우, 서로 다른 프로세스에서 오브젝트를 공유하기 위해서는 상속을 하거나 DuplicateHandle() 함수를 사용해야 한다. 그러나 Named 오브젝트는 오브젝트 이름을 이용하여 공유할 수 있다.
널문자 ( '\0' ) 로 끝나는 문자열을 pszName 인수로 전달하면 Named 오브젝트를 생성할 수 있다. Name 은 최대 MAX_PATH ( 260 으로 정의되어 있음 ) 길이 만큼 사용할 수 있다. 하지만 아쉽게도 Microsoft 에서는 커널 오브젝트의 Name 을 할당하는 것에 대한 어떠한 방법도 제공하지 않는다. 즉, 동일한 Name 이 존재하는지에 대한 확인을 할 수 없다. 게다가 하나의 Name space 를 공유하기 때문에 다음과 같은 예에서 CreateSemaphore() 함수는 NULL 값을 반환한다.
HANDLE hMutex = CreateMutex( NULL, FALSE, "JeffObj" );
HANDLE hSem = CreateSemaphore( NULL, 1, 1, "JeffObj" );
DWORD dwErrorCode = GetLastError();
위의 코드를 실행한 후 dwErrorCode 변수는 ERROR_INVALID_HANDLE (6) 값을 반환받게 된다. 그러나 이 에러 코드는 무엇이 잘못되었는지 알 수 없다. 여기에 대한 자세한 설명이 없기 때문이다.
다음 코드와 같이 프로세스 A 를 실행하였을 경우
HANDLE hMutexProcessA = CreateMutex( NULL, FALSE, "JeffMutex" );
이 코드는 JeffMutex 라는 새로운 Mutex 커널 오브젝트를 생성한다. 여기서 프로세스 A 의 hMutexProcessA 를 상속할 필요는 없다. Named 오브젝트는 그럴 필요가 없기 때문이다.
그리고 난 후, 프로세스 B 를 생성한다. 여기서 프로세스 B 는 프로세스 A 의 자식 프로세스일 필요는 없다. 이것은 상속 대신에 Named 오브젝트를 사용하는 이점이다. 프로세스 B 는 다음과 코드를 실행한다.
HANDLE hMutexProcessB = CreateMutex( NULL, FALSE, "JeffMutex" );
프로세스 B 가 CreateMutex() 함수를 호출 할 경우, 시스템은 먼저 JeffMutex 라는 오브젝트가 존제하는지 검색한다. 오브젝트가 존재하면 동일한 오브젝트 타입인지 확인하고 오브젝트의 Security 를 검사하여 함수를 호출한 프로세스가 접근할 수 있는지 검사한다. 이 과정을 통과하였을 때 시스템은 프로세스 B 의 핸들 테이블에서 비어있는 곳을 찾아서 시스템에 존재하는 커널 오브젝트의 핸들을 초기화 한다. 만약 모든 것이 일치하지 않을 경우 커널 오브젝트를 접근할 수 없으며 CreateMutex() 함수는 실패한다 ( NULL 값을 반환 ).
프로세스 B 가 CreateMutex() 함수 호출을 성공하였을 때, Mutex 오브젝트를 실제로 생성되는 것이 아니다. 그 대신 프로세스 B 는 커널 내에 존재하는 Mutex 오브젝트를 식별할 수 있는 핸들 값만을 할당받을 뿐이다. 물론, 프로세스 B 의 핸들 테이블에서 참조하고 있기 때문에 Mutex 오브젝트의 usage count 는 증가한다. 즉 프로세스 A 와 B 가 모두 핸들을 닫기 전까지는 오브젝트는 제거되지 않는다. 그리고 두 개의 프로세스가 하나의 커널 오브젝트를 조작하더라도 서로의 핸들 값은 동일하지 않다는 것을 알아야 한다.
참고
Name 을 공유하는 커널 오브젝트를 사용할 때 매우 중요하고 자세히 알아야할 것이 있다. 프로세스 B 가 CreateMutex() 함수를 호출할 때 두번째 인수에 Security Attribute 정보를 전달할 경우, 오브젝트 Name 이 존재하면 이 인수는 무시된다. 이런 경우 응용 프로그램은 새로운 커널 오브젝트를 생성하는 것과 Create*() 함수를 호출한 후 GetLastError() 함수 호출하여 이미 존재하는 오브젝트를 단순히 여는 것 중에서 선택할 수 있다.
HANDLE hMutex = CreateMutex( &sa, FALSE, "JeffObj" );
if( GetLastError() == ERROR_ALREADY_EXISTS ) {
// Opened a handle to an existing object.
// sa.lpSecurityDescriptor and the second parameter
// (FALSE) are ignored.
} else {
// Created a brand new object.
// sa.lpSecurityDescriptor and the second parameter
// (FALSE) are used to construct the object.
}
Name 으로 오브젝트를 공유하기 위한 방법으로 Create*() 함수를 호출하는 대신에 다음과 같이 Open*() 함수를 호출할 수 있다.
HANDLE OpenMutex(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
HANDLE OpenEvent(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
HANDLE OpenSemaphore(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
HANDLE OpenWaitableTimer(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
HANDLE OpenFileMapping(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
HANDLE OpenJobObject(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
PCTSTR pszName
);
모든 함수들은 동일한 프로토타입을 갖고 있다. 마지막 인수인 pszName 는 커널 오브젝트의 Name 을 지정한다. 이 인수는 NULL 값을 전달할 수 없으며 널문자 ( '\0' ) 로 끝나는 문자열을 전달해야 한다. 그리고 이들 함수는 커널 오브젝트의 단일 Name space 에서 일치하는 오브젝트를 검색한다. Name 과 일치하는 커널 오브젝트가 없을 경우, 이 함수들은 NULL 값을 반환하며 GetLastError() 함수는 ERROR_FILE_NOT_FOUND (2) 값을 반환한다. 그러나 지정된 Name 의 커널 오브젝트가 존재한다면 오브젝트 타입이 일치하고 dwDesiredAccess 인수로 전달된 접근 권한을 허용한 경우로 함수를 호출한 프로세스 핸들 테이블은 업데이트 되고 오브젝트의 usage count 는 증가한다. 또한 반환된 핸들은 bInheritHandle 인수를 TRUE 값으로 전달하였다면 상속도 가능하다.
Create*() 함수와 Open*() 함수 사이에서의 큰 차이점은 오브젝트가 존재하지 않을 경우, Create*() 함수는 오브젝트를 생성하고 Open*() 함수는 단순히 함수 호출을 실패한다.
앞에서 언급했지만, Microsoft 는 유일한 오브젝트 Name 을 어떻게 만드는지에 대한 가이드라인을 제공하지 않는다. 즉, 서로 다른 두 회사에서 만든 두 개의 프로그램이 "MyObject" 라는 Name 의 오브젝트를 생성하기 위하여 시도할 경우 문제가 발생할 수 있다는 것이다. 이와 같은 문제를 방지하기 위해서는 오브젝트 Name 을 GUID 를 생성한 후 GUID 문자열을 사용하기를 권한다.
Named 오브젝트는 일반적으로 응용 프로그램의 다수의 인스턴스가 실행되는 것을 방지하기 위하여 사용된다. 이것은 main() 또는 WinMain() 함수에서 Named 오브젝트를 생성하기 위하여 단순히 Create*() 함수를 호출하는 것으로 가능하다 ( 오브젝트 타입이 일치하지 않아도 된다 ). Create*() 함수를 실행한 후 GetLastError() 함수를 호출하여 반환값이 ERROR_ALREADY_EXISTS 일 경우, 프로그램이 실행되고 있는 상태이므로 새로 실행된 인스턴스는 종료한다. 이와 같은 코드는 아래와 같다.
int WINAPI WinMain( HINSTANCE hinstExe, HINSTANCE, PSTR pszCmdLine,
int nCmdShow )
{
HANDLE h = CreateMutex( NULL, FALSE,
"{FA531CC1-0497-11d3-A180-00105A276C3E}" );
if( GetLastError() == ERROR_ALREADY_EXISTS ) {
// There is already an instance of this application running.
return ( 0 );
}
// This is the first instance of this application running.
...
// Before exiting, close the object.
CloseHandle( h );
return ( 0 );
}
3.4 Terminal Service Name Spaces #
Terminal 서버는 앞에서 보았던 시나리오 중에서 일부분을 바꿔야 한다. Terminal 서버 머신은 커널 오브젝트를 위한 다수의 Name space 가 필요하다. 그 중에 하나의 Global name space 가 있다. 이것은 일부 또는 모든 클라이언트 세션에서 접근할 수 있는 커널 오브젝트에 의해 사용되며 주로 서비스에 의하여 사용될 Name space 가 된다. 그리고 각 클라이언트 세션은 각각의 Name space 를 갖고 있다. 이것은 두개 또는 그 이상의 세션에서 실행되는 같은 응용 프로그램의 커널 오브젝트를 보호한다. 즉, 같은 Name 으로 공유되는 오브젝트라도 서로 다른 세션에서는 접근할 수 없도록 한다. Terminal 서버를 제공하지 않는 머신에서는 서비스와 응용 프로그램은 앞에서 보았던 것과 같이 동일한 커널 오브젝트 Name space 를 공유한다. 그러나 Terminal 서버 머신에서는 동일하지 않다.
서비스의 Named 커널 오브젝트는 언제나 Global name space 내에 있다. 기본적으로 Terminal 서버 내에 응용 프로그램의 Named 커널 오브젝트는 Session name space 내에 있다. 그러나 "Global\" 를 Name 앞에 붙이게 되면 커널 오브젝트를 Global name space 에 강제적으로 넣을 수 있으며 다음과 같이 실행할 수 있다.
HANDLE h = CreateEvent( NULL, FALSE, FALSE, "Global\\MyName" );
또한 "Local\" 를 Name 앞에 붙임으로서 명시적으로 커널 오브젝트를 Session Name space 에 넣을 수 있다. 코드는 다음과 같다.
HANDLE h = CreateEvent( NULL, FALSE, FALSE, "Local\\MyName" );
Microsoft 는 Global 과 Local 을 특정한 Name space 를 제외한 오브젝트 Name 으로 사용할 수 없도록 예약어로 지정하는 것을 고려하고 있다. 또한 현재 의미하는 것은 없지만 Session 도 예약어로 지정하는 것을 고려중이다. 주의할 것은 이들 예약어는 대소문자를 구별하며, 끝으로 Terminal Server 가 실행되지 않는 머신에는 이들 예약어는 무시된다.
3.5 Duplicating Object Handles #
서로 다른 프로세스 사이에서 커널 오브젝트를 공유하는 마지막 방법으로 DuplicateHandle() 함수를 사용하는 것이다.
BOOL DuplicateHandle(
HANDLE hSourceProcessHandle,
HANDLE hSourceHandle,
HANDLE hTargetProcessHandle,
PHANDLE phTargetHandle,
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwOptions
);
단순히, 이 함수는 하나의 프로세스 핸들 테이블의 핸들을 다른 프로세스의 핸들 테이블로 복사한다. DuplicateHandle() 함수는 여러개의 인수를 가지고 있지만 실제로 아주 간단하다. 이 함수의 가장 일반적인 사용법은 시스템에서 실행중인 3 개의 서로 다른 프로세스를 사용하는 것이다.
DuplicateHandle() 함수의 첫번째와 세번째 인수 ( hSourceProcessHandle 와 hTargetProcessHandle ) 는 커널 오브젝트 핸들이며 이 함수를 호출하는 프로세스와 관련된 핸들이다. 게다가 이 두 개의 인수는 프로세스 타입의 커널 오브젝트로 DuplicateHandle() 함수의 호출이 실패하였을 경우, 다른 타입의 커널 오브젝트가 전달되었는지 확인해 보아야 한다.
두번째 인수인 hSourceHandle 는 다양한 타입의 커널 오브젝트 핸들이 가능하다. 그러나 이 핸들 값은 DuplicateHandle() 함수를 호출하는 프로세스와 관련된 것이 아니다. 그 대신에 hSourceProcessHandle 핸들에 의하여 식별되는 프로세스와 관련되어 있다. 네번째 인수인 phTargetHandle 는 Source 의 핸들 정보를 복사한 Target 핸들 테이블의 인덱스를 받기 위한 HANDLE 변수의 주소로 hTargetProcessHandle 핸들에 의하여 식별되는 프로세스와 관련된 핸들 값을 받게 된다.
DuplicateHandle() 함수의 마지막 3 개의 인수는 access mask 값과 상속을 설정하는 플래그 값, 그리고 옵션을 지정할 수 있도록 허용한다. dwOptions 인수는 0 또는 두 개의 플래그 ( DUPLICATE_SAME_ACCESS 와 DUPLICATE_CLOSE_SOURCE ) 를 조합하여 사용할 수 있다.
DUPLICATE_SAME_ACCESS 를 지정하면 Source 프로세스의 핸들과 동일한 access mask 값을 Target 핸들로 복사하도록 DuplicateHandle() 함수에게 알려준다. 이 플래그를 사용하면 dwDesiredAccess 인수는 무시된다.
DUPLICATE_CLOSE_SOURCE 를 지정하면 Source 프로세스에서 핸들을 닫을 수 있도록 한다. 이것은 다른 프로세스에서 사용되는 커널 오브젝트를 하나의 프로세스에서 관리하기 쉽도록 만든다. 이 플래그를 사용하게 되면 커널 오브젝트의 Usage count 의 영향을 받지 않는다.
DuplicateHandle() 함수가 어떻게 처리되는지 예를 통하여 알아보자. 여기서 프로세스 S 는 Source 프로세스로 현재 커널 오브젝트를 갖고 있다. 그리고 프로세스 T 는 Target 프로세스로 커널 오브젝트 핸들을 얻어야 한다. 프로세스 C 는 DuplicateHandle() 함수 호출을 실행할 Catalyst 프로세스이다.
프로세스 C 의 핸들 테이블 ( 표 4 ) 는 2 개의 핸들 값 ( 1 과 2 ) 를 갖고 있다. 핸들 값 1 과 2 는 각각 프로세스 S 와 프로세스 T 의 프로세스 타입의 커널 오브젝트 핸들 값이다.
<표 4> 프로세스 C 의 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0xF0000000 (Process S's kernel object) | 0x???????? | 0x00000000 |
| 2 | 0xF0000010 (Process T's kernel object) | 0x???????? | 0x00000000 |
<표 5> 는 프로세스 S 의 핸들 테이블이며 하나의 핸들 값 2 를 갖고 있다. 이 핸들은 어떤 타입의 커널 오브젝트도 가능하며 프로세스 타입의 오브젝트 핸들일 필요는 없다.
<표 5> 프로세스 S 의 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0x00000000 | (N/A) | (N/A) |
| 2 | 0xF0000020 (any kernel object) | 0x???????? | 0x00000000 |
<표 6> 은 프로세스 C 가 DuplicateHandle() 함수를 호출하기 전의 프로세스 T 의 핸들 테이블이다. 이 테이블은 하나의 핸들 값 2 만을 갖고 있으며, 핸들 1 은 사용하지 않고 있다.
<표 6> DuplicateHandle() 함수를 호출하기 전, 프로세스 T 의 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0x00000000 | (N/A) | (N/A) |
| 2 | 0xF0000030 (any kernel object) | 0x???????? | 0x00000000 |
프로세스 C 가 다음과 같은 코드로 DuplicateHandle() 함수를 호출할 경우, <표 7> 과 같이 프로세스 T 의 핸들 테이블만 바뀌게 된다.
DuplicateHandle(1, 2, 2, &hObj, 0, TRUE, DUPLICATE_SAME_ACCESS);
<표 7> DuplicateHandle() 함수를 호출한 후, 프로세스 T 의 핸들 테이블
| Index | Pointer to Kernel Object Memory Block | Access Mask (DWORD of Flag Bits) | Flags (DWORD of Flag Bits) |
| 1 | 0xF0000020 | 0x???????? | 0x00000001 |
| 2 | 0xF0000030 (any kernel object) | 0x???????? | 0x00000000 |
프로세스 S 의 핸들 테이블의 핸들 2 가 프로세스 T 의 핸들 테이블의 핸들 1 로 복사된다. 또한 DuplicateHandle() 함수는 프로세스 C 의
hObj 변수로 프로세스 T 의 핸들 테이블에 새롭게 할당된 핸들 값 1 을 반환한다.
그리고 DuplicateHandle() 함수에 DUPLICATE_SAME_ACCESS 플래그를 전달하였기 때문에 프로세스 S 의 핸들과 동일한 access mask 값을 프로세스 T 의 핸들에 설정되었다. 또한 DUPLICATE_SAME_ACCESS 플래그를 전달하였으므로 dwDesiredAccess 인수는 무시된다. 마지막으로 bInheritHandle 인수에 TRUE 값을 전달하기 때문에 상속 가능하도록 플래그가 설정되었다.
위의 예에서 보았던 것과 같이 하드 코딩되어 있는 값을 DuplicateHandle() 함수의 인수로 전달하면 절대 안된다. 이 값들은 단지 이 함수가 어떻게 동작하는지 알아보기 위하여 예를 들었을 뿐이다. 따라서 실제 응용 프로그램에서는 변수를 이용하여 다양한 핸들 값을 DuplicateHandle() 함수로 전달해야 할 것이다.
상속과 같이 DuplicateHandle() 함수의 이상한 것 중 하나는 새로운 커널 오브젝트 핸들을 사용할 수 있다는 것을 Target 프로세스에게 알려주지 않는다는 것이다. 그러므로 프로세스 C 는 hObj 변수의 핸들 값을 IPC ( Inter Process Communication ) 와 같은 것을 이용하여 프로세스 T 에게 새로운 커널 오브젝트 핸들 사용할 수 있도록 알려주어야 한다. 분명한 것은 이미 프로세스가 실행되고 있으므로 command-line 이나 프로세스 T 의 환경 변수를 사용할 수 없다는 것이다. 따라서 Window message 나 다른 IPC 메카니즘을 사용해야 한다.
여기서는 단지 DuplicateHandle() 함수의 가장 일반적인 사용방법에 대하여 설명하였다. 이 함수는 대단히 유연한 함수지만 3 개의 프로세스가 연관된 경우는 대단히 드물다 ( 프로세스 S 가 사용하고 있는 핸들 값을 프로세스 C 가 알고 있다는 것은 대단히 어려운 일이기 때문이다 ). 일반적으로 DuplicateHandle() 함수는 서로 연관 있는 두 개의 프로세스에 의하여 사용된다. 다른 프로세스가 갖고 있는 커널 오브젝트를 사용해야 하거나 다른 프로세스에서 사용할 수 있도록 커널 오브젝트를 전달해야 하는 상황을 가정할 수 있다. 예를 들어 프로세스 S 가 갖고 있는 커널 오브젝트를 프로세스 T 로 전달한다고 할 경우, 다음과 같이 DuplicateHandle() 함수를 호출한다.
// All of the following code is executed by Process S.
// Create a mutex object accessible by Process S.
HANDLE hObjProcessS = CreateMutex( NULL, FALSE, NULL );
// Open a handle to Process T's kernel object.
HANDLE hProcessT = OpenProcess( PROCESS_ALL_ACCESS, FALSE,
dwProcessIdT );
HANDLE hObjProcessT; // An uninitialized handle relative to Process T.
// Give Process T access to our mutex object.
DuplicateHandle( GetCurrentProcess(), hObjProcessS, hProcessT,
&hObjProcessT, 0, FALSE, DUPLICATE_SAME_ACCESS );
// Use some IPC mechanism to get the handle
// value in hObjProcessS into Process T.
...
// We no longer need to communicate with Process T.
CloseHandle( hProcessT );
...
// When Process S no longer needs to use the mutex, it should close it.
CloseHandle( hObjProcessS );
GetCurrentProcess() 함수는 이 함수를 호출하는 프로세스를 항상 확인할 수 있는 pseudo 핸들을 반환한다 ( 위의 예에서 프로세스 S ). DuplicateHandle() 함수를 호출하여 반환된 hObjProcessT 변수는 프로세스 S 에서 사용되는 hObjProcessS 변수의 핸들과 동일한 오브젝트를 가리키는 프로세스 T 의 핸들 값을 갖고 있다. 따라서 프로세스 S 는 다음과 같은 코드를 절대로 실행할 수 없다.
// Process S should never attempt to close the
// duplicated handle.
CloseHandle( hObjProcessT );
만약 프로세스 S 가 이 코드를 실행한다면, 성공하거나 실패할 수도 있다. hObjProcessT 변수의 핸들 값과 동일한 커널 오브젝트를 사용할 수 있다면 프로세스 S 는 성공할 것이다. 그러나 이것은 프로세스 S 의 어떤 오브젝트를 더 이상 사용할 수 없도록 닫는 결과를 가져오게 되므로 응용 프로그램이 이상하게 동작하게 되는 원인이 될 수 있다.
DuplicateHandle() 함수의 또 다른 사용법은 읽기와 쓰기가 가능한 file-mapping 오브젝트를 프로세스가 갖고 있다고 가정하고 어떤 함수를 호출할 때, file-mapping 오브젝트를 읽기만 가능하도록 할 수 있다. 이것은 응용 프로그램을 보다 안전하고 튼튼하게 ( robust ) 하기 위하여 DuplicateHandle() 함수를 사용하여 이미 존재하는 오브젝트에 대하여 읽기만 가능한 새로운 핸들을 만든다. 이렇게 만들어진 읽기 전용 핸들을 함수로 전달한다. 이 방법은 함수 내에서 file-mapping 오브젝트에 대하여 절대로 쓰기를 할 수 없다. 다음과 같이 예를 들 수 있다.
int WINAPI WinMain( HINSTANCE hinstExe, HINSTANCE,
LPSTR szCmdLine, int nCmdShow )
{
// Create a file-mapping object; the handle has read/write access.
HANDLE hFileMapRW = CreateFileMapping( INVALID_HANDLE_VALUE,
NULL, PAGE_READWRITE, 0, 10240, NULL );
// Create another handle to the file-mapping object;
// the handle has read-only access.
HANDLE hFileMapRO;
DuplicateHandle( GetCurrentProcess(), hFileMapRW, GetCurrentProcess(),
&hFileMapRO, FILE_MAP_READ, FALSE, 0 );
// Call the function that should only read from the file mapping.
ReadFromTheFileMapping( hFileMapRO );
// Close the read-only file-mapping object.
CloseHandle( hFileMapRO );
// We can still read/write the file-mapping object using hFileMapRW.
...
// When the main code doesn’t access the file mapping anymore,
// close it.
CloseHandle( hFileMapRW );
}
CategoryTranslation
