요즘은 매우 바쁘답니다. 그래서... 이제야 글하나를 겨우 쓰게 되었다는... -_-;

Run As Implementation using Process class

눈코 뜰새 없이 바쁘다는 말을 들어본 적이 있는가? 아놔... 요즘 필자가 하고 싶은 말이 바로 이 말이 되겠다. 삼성동에서 종로와 분당을 넘나들며 여기저기를 휘젓고 다니는 필자는 Vista 출시로 인한 어플리케이션 호환성 문제에 대한 컨설팅을 위주로 해서 이런저런 프로젝트에 대추 놔라 감 놔라 하면서 졸라 아는 척만 하고 다니고 있는 중이다. 엔지니어에게 눈코 뜰새 없이 바쁘다는 것은 좋지 않은 것이다. 특히 우리들 같이 춥고 배고프고 눈곱 끼고 등 시려운 개발자들에겐 더욱 그러하며, 최근 MS 관련 기술로 밥 벌어 먹고 사는 인간들에게는 더더욱 그렇다. WPF 니 WCF 니 새로운 기술들이 쏟아져 나오는 상황에 새로운 운영체제로 Vista 란 놈까지 나타났으니 준비해야 할 것이 오죽이나 많은가? 엔지니어가 바쁘다는 것은 회사의 입장으로 보았을 때는 더 많은 매출과 더 많은 비즈니스 찬스를 갖게 되어 회사가 기뻐할 수 있을 지는 모른다. 하지만 장기적으로 보았을 때 엔지니어가 지속적으로 바쁜 나날을 보내게 된다면 좋을 것은 하나도 없다고 본다. 그들이 바쁜 나날을 보내게 되면 당연히 새로운 기술을 준비하거나 현재의 기술에 대한 심화를 할 겨를이 없을 것이고, 바쁜 일과에 찌들다 보면 시간이 생기더라도 지쳐버린 몸과 정신에 주저 앉아 버릴 수 있기 때문이다. 이러다 보면 그는 더 이상 엔지니어로서 롱런 하기 힘들게 되어 버릴 것이고 많은 경우에 burn-out 되어 버리는 경우를 종종 보곤 한다. 엔지니어는 refresh할 시간이 필요하다. 안타까운 일이지만 SI 업계에 종사하고 있다면 이러한 현상은 더욱 두드러지곤 한다. 더욱 안타까운 것이 이러한 문제에 대한 특별한 대안이 없다는 것이다. 언젠가는 숙련된 개발자 찾기가 하늘에 별따기 보다 힘든 상황이 올지도 모른다. (그때를 대비해서 겨울잠이 나 자볼까 생각도 하는데... -_-;)

About Run As...

개소리는 집어 치우고 본론으로 들어가 보자.

Run as는 Windows 2000 시절부터 지원되는 윈도우 운영체제의 한 기능이다. 역사(?)를 이야기 하자면 Windows NT가 설계되었을 때 관리자(administrator)와 일반 사용자가 엄격히 구분되어 각기 주어진 권한 내에서 작업을 하기를 기대했다. 결과적으로 이런 기대는 말짱 꽝이 되어 버렸다. 일반 사용자가 할 수 있는 일이라곤 별로 없었기 때문에 클라이언트 버전의 윈도우에서 대부분 아니 거의 전부의 사용자가 관리자 계정에서 작업하기를 바랬기 때문이다. 당연한 것이 서버도 아닌 내 PC를 내 마음대로 사용하지 못한다는 것이 가당키나 한 일인가? 일반 사용자 계정으로 로그온 해서 일반 작업을 하다가 설치를 하거나 시스템을 관리해야 하는 상황이 오면 로그 오프를 하고 다시 관리자 계정으로 로그온 하여 작업을 해야 하니 그 불편함이 이루 말할 수 없었던 것이다.

그래서 Windows 2000에서는 필요에 따라 로그온 된 사용자 계정이 아닌 특정 계정으로 프로그램(프로세스)를 구동시키는 방법으로써 Run As 기능이 추가된 것이다. 사용자가 사용할 수 있는 RunAs.exe 란 커맨드 라인 유틸리티가 제공되었고 쉘(shell)은 "다음 계정으로 수행..." 이라는 메뉴가 추가 되었으며 당연 빤쑤로 관련 API로서 CreateProcessAsUser() 라는 함수가 제공되었다.

Windows 2000의 노력에도 불구하고 큰 진전은 없었다. 여전히 사용자들은 편리함을 추구했고 관리자 권한을 갖는 계정을 사용하기를 원했다. 덕분에 관리자 계정에 의해 구동되는 쉘과 브라우저 역시 관리자 권한을 갖게 되고, 이들에 의해 다운로드 되고 구동되는 바이러스와 스파이웨어 역시 관리자 권한을 갖게 되는 것이다. 바이러스와 스파이웨어가 시스템에 대해 거의 무한정의 권한을 갖고 시스템을 휘젓는 상황이 자주 발생하게 된 것이다.

그래서... 바이러스와 스파이웨어들에 대해 골머리를 앓던 마이크로소프트는 극단(?)의 조치를 취하게 되는데... 그것이 바로 Windows Vista의 UAC(User Access Control)이란 기능이다. UAC는 관리자 계정이 로그온 하면 관리자 권한을 제한하는 기능으로써 보다 윈도우 시스템을 안전하게 유지하고자 하는 마이크로소프트의 몸부림이라고 볼 수 있겠다. UAC에 대해서 이 글에서는 더 이상 언급하지 않겠다. UAC가 무엇인지 좀 더 알고 싶다면 Windows Vista Application Development Requirements for User Account Control 란 글을 읽어 보기 바란다. 그리고 정성태씨의 홈페이지에 가면 Vista와 UAC에 대한 아주 좋은 글을 많이 접할 수 있다.

필자가 Run As 기능과 관련 API에 관심을 갖게 된 동기도 Vista에서 UAC를 피하는 방법이 있지 않을까 하고 삽질을 하던 차에 관심을 갖게 된 것이다. 결론은 UAC를 꺼버리는 것 외엔 UAC를 피하는 쓸만한 방법이 거의 없다는 것이다(MS가 독하게 맘을 먹은 듯하다). 굳이 피할 이유도 없지만 말이다.

Using P/Invoke

Run As를 구현하기 위해서는 CreateProcessAsUser() 라는 API를 호출하면 된다. 하지만 이 API가 요구하는 특권(priviliege)은 매우 높아서 일반 관리자 계정도 이 권한을 기본적으로 갖고 있지 않다. SYSTEM 계정이라면 모를까... 그렇다면 Runas.exe 커맨드와 쉘은 어떻게 다른 계정으로 작동하는 프로세스를 구동할 수 있을까?

답은 Secondary Logon 이라고 하는 시스템 서비스가 갖고 있다. 이 서비스는 SYSTEM 계정으로 작동하는데, Runas.exe 커맨드나 쉘의 요청을 받아 CreateProcessAsUser() 함수를 호출하여 현재 로그온 된 사용자가 아닌 다른 사용자로서 프로세스를 구동하게 해준다.

삽질 잘하는 필자, 테스트를 위해서 CreateProcessAsUser를 이용하여 Run as를 구현해 보고 싶었다. CreateProcessAsUser를 호출하려면 먼저 LogonUser 라는 API를 먼저 호출해야만 하고 이 함수가 반환하는 액세스 토큰(access token)을 CreateProcessAsUser에게 매개변수로 넘겨주어야 한다.

닷넷에서 이 두 짐승들을 호출하려면 매우 많은 상수와 P/Invoke 선언을 해주어야 한다. LogonUser()에 대한 interop 코드는 필자의 ASP.NET 상에서 폴더 공유를 다루는 글에서 찾을 수 있다. 상당히 복잡타.... CreateProcessAsUser 함수에 비하면 LogonUser 함수는 양반 축에 속한다. CreateProcessAsUser 함수는 자그마치 11개의 매개변수를 취하며 그 중 다수가 구조체이기 때문에 더욱 더 많은 Interop 코드를 요구한다.

LogonUser 함수와 CreateProcessAsUser 함수를 사용한 Run As 기능의 구현이 매우 복잡하다는 것을 마이크로소프트도 눈치를 챘는지 Windows XP에서는 이들 두 함수를 한방에 처리할 수 있는 CreateProcessWithLogonW 라는 새로운 API를 제공한다. 이 함수는 내부적으로 Run as가 요구하는 모든 더러운 작업들을 처리해 줄 뿐만 아니라, 이 함수를 호출하기 위해 요구하는 특권 역시 거의 없다.

하지만 이 함수도 Win32 API일 뿐이다. 11개의 매개변수를 취하는 CreateProcessWithLogonW()를 닷넷에서 호출하려면 역시 매우 많은 상수들과 구조체, 그리고 함수 자체에 대한 선언을 해주어야만 한다.

필자가 구현해 본 결과(필자가 생각하기에도 필자는 정말 삽질 하나는 끝내게 잘한다... -_-), LogonUser, CreatProcessAsUser, CreateProcessWithLogonW 함수들과 관련 상수들, 구조체들에 대한 Interop '선언'하는 데만 500 여 라인의 코드가 필요했다. 물론 그 중 1/3이 주석이었지만 말이다.

여기서 그 코드를 보이진 않겠다. 보여줄 가치도 없기에...

Using System.Diagnostics.Process class

이번 포스트에서 하고 싶은 이야기는 우리의 친절한 닷넷 프레임워크 2.0은 이미 Run As 기능을 구현하고 있다는 것이다. 조금만 읽어 보면 필자가 앞서 Win32 API들에 대한 Interop 선언을 한 것이 왜 삽질인가를 이제 이해를 할 것이다.

System.Diagnostic.sProcess 클래스는 이미 시스템상에서 구동중인 프로세스의 정보를 제공할 뿐만 아니라 Start 메쏘드를 통해 새로운 프로세스를 구동하는 기능도 제공하고 있다는 것은 이미 잘 알고 있을 것이다. 이 Start 메쏘드는 ProcessStartInfo 클래스를 매개변수로 취하기도 하는데 이 클래스는 새로 시작할 프로세스에 대한 다양한 정보(환경변수, 작업 디렉터리, 윈도우 최대화 여부 등)를 설정하는데 사용하곤 한다.

닷넷 프레임워크 2.0에는 ProcessStartInfo 클래스에 새로운 속성들이 추가되었는데 이들 중 UserName 속성, Password 속성, Domain 속성, LoadUserProfile 속성이 Run As를 구동하는데 사용되는 속성들이다. 즉, ProcessStartInfo 클래스의 이들 속성에 프로세스를 구동하는데 사용할 사용자 계정, 암호, 계정의 도메인(Windows 도메인)을 설정하고 Process.Start 메쏘드를 호출하면 해당 계정으로 작동하는 프로세스가 만들어진다는 것이다. 이미 눈치를 챈 독자들도 있겠지만 Process.Start 메쏘드가 특정 계정으로 프로세스를 구동할 때 사용하는 API가 바로 앞서 소개한 바 있는 CreateProcessWithLogonW 라는 API 가 되겠다. 이것이 바로 Run As 기능이 아니고 무엇인가?

리스트1. ProcessStartInfo 클래스와 Process.Start를 이용한 RunAs 구현

소소스 코드에 주석으로 대부분 설명이 되어 있지만 UserName, Password 속성을 주면 UseShellExecute 속성을 false로 설정해야만 하며(15번째 라인), UserName, Password 속성이 주어짐에 따라 WindowStyle 속성, ErrorDialog 속성 등의 값은 무시된다(12번째 라인)는 점을 알아 두자.

재미삼아 만들어 본 예제 코드 화면은 다음과 같다.

화면1. 닷넷으로 구현한 RunAs 유틸리티 화면

How about C++/CLI ?

이제부터 필자가 얘기할 내용은 지난 포스트에서 소개한 C++/CLI에 대한 내용이다. C++을 전혀 모르거나 관심이 없는 독자들은 시간 낭비하지 말고 다른 일을 하는 것이 좋을 수도 있다. 하지만 한번쯤은 읽어 보아도 손해는 되지 않을 것 같다는 생각이 똥꼬 깊숙한 곳에서 요동을 치는 이유는 무엇일까? 얌... 드러... -_-;

Process 클래스의 Start 메쏘드를 사용할 때의 단점은 새로이 생성하는 프로세스가 생성하는 메인 윈도우의 위치를 지정한다거나 윈도우를 최대화 한다거나 최소화 하는 등, 원래 CreateProcessWithLogonW API 함수가 제공하는 모든 기능을 모두 사용할 수 없다는 것이다. 그렇다고 조낸 복잡하게 CreateProcessWithLogonW 함수와 관련된 상수들, 구조체들을 모두 선언하자니 삽질이고...

그래서 지난 포스트에서 소개한 바 있는 방법을 써먹어 보기로 했다. 즉, CreateProcessWithLogonW를 호출하는 코드를 C++/CLI로 작성하고 이 코드를 닷넷 DLL 어셈블리로서 컴파일 한다. 그리고 UI를 담당하는 코드는 편리(?)한 C#으로 작성하는 것이다. 필자의 예제처럼 간단한 UI 만을 가진다면 전체 코드를 C++/CLI로 작성할 수도 있겠지만 업무용 어플리케이션이나 상업용 유틸리티 등과 같은 복잡한 UI를 갖는 경우에는 생각해 볼만한 방법이기 때문이다.

다음 리스트2 코드는 C++/CLI를 이용하여 CreateProcessWithLogonW API 함수를 호출하는 래퍼 클래스를 보여주고 있다. 복잡한 매개변수를 취하지 않고 필요한 매개변수만을 취하고 있으며, C/C++로 API를 호출하는 코드를 작성하듯이 Win32에서 제공하는 다양한 상수와 구조체를 사용하고 있다. 물론 이들 상수와 구조체에 대한 선언은 windows.h 헤더에 있는 것을 모두 사용할 수 있다. 상세한 설명은 글을 지루하게 만들 뿐만 아니라 필자의 귀차니즘을 심히 자극하는 바... C++/CLI를 정말 공부하고 싶은 독자들은 스스로 공부하길 바란다...

리스트2. C++/CLI를 이용하여 Win32 API를 호출하는 래퍼 클래스

이제 리스트2 에서 작정한 코드를 컴파일 하여 DLL로 만들고 C# 프로젝트에서 참조하여 Win32 클래스의 메쏘드를 호출하기만 하면 된다. 다음과 같이 말이다.

Conclusion

우리의 친절한 닷넷씨는 Process 클래스와 ProcessStartInfo 클래스를 이용하여, 로그온 한 사용자 계정이 아닌 특정 계정으로 프로세스를 구동하는 Run As 기능을 제공한다. 어떻게 보면 아무짝에도 쓸모가 없을 수 있지만 필요에 따라서 요긴하게 써먹을 수도 있으니 잘 기억해 두었다가 나중에 써먹을 수 있도록 노력해 보자.

덤으로 Process 클래스와 C++/CLI를 사용한 예제 코드가 제공되니 관심 있는 독자는 다운로드 받아보길 바란다.

• Process 클래스와 C++/CLI를 이용한 Run as 예제 코드 

강대욱!!! 코딩 백번 !!!