 |
|
난이도 : 중급 Kurt A. Riley, IT 컨설턴트
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 5 월 06 일 AIX®에서 UID나 GID를 변경하려는 경우 파일 소유권이 어떻게 바뀌는지 올바로 이해해야 합니다. 확실히 이해하지 못한 채 UID나 GID를 변경했다가는 서버나 환경에 심각한 문제를 초래할 수 있습니다.
IBM® AIX® 운영체제에서 UID와 GID를 변경하는 작업은 유닉스(UNIX®) 관리자 입장에서 그리 달가운 작업이 아니다. 흔히 끔찍한 작업이라 여겨지만, 시스템 일관성을 유지하려면, 관리자가 반드시 수행해야 하는 작업이기도 하다. 그러나 UID와 GID를 섣불리 변경했다가는 시스템 환경에 심각한 악영향을 미치므로 각별히 주의해야 한다. 가장 중요한 것은, 관리자는 변경이 초래할 결과를 충분히 이해해야 한다는 점이다. 그런 다음, 올바로 변경하는 방법을 익히고 (필요하다면) 유닉스 스크립트로 변경 과정을 자동화한다.
UID와 GID: 간략한 소개
AIX에서 UID는 파일 소유권을, GID는 그룹 접근 권한을 결정한다. UID와 GID는 0에서 대략 65,535 사이 정수 값이다(최대값은 사용 중인 유닉스 버전에 따라 달라진다). 각 사용자 계정은 이 범위 내에서 고유한 UID로 변환된다. 유닉스에서 특정 사용자에게 할당된 UID와 기본 GID를 확인하려면 /etc/passwd 파일을 살펴본다.
$grep bduda /etc/passwd
bduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh
|
세 번째 필드 300이 UID고, 네 번째 필드 350이 사용자가 속한 기본 그룹 GID다. 그룹 정보를 좀 더 자세히 살피려면 /etc/group 파일을 확인한다.
$grep ":350:" /etc/group
security:!:350:bduda
|
위에서 보듯이, 사용자 bduda는 security라는 그룹에 기본적으로 속한다. 사용자 bduda의 기본 그룹이 security이므로 bduda가 생성하는 모든 파일 역시 이 GID를 따른다.
UID와 GID 선택하기
일반적으로 UID와 GID 숫자 범위는 기본적인 규칙을 따른다. AIX에서는 관리자가 할당을 위한 UID 시작 범위를 지정한다. 100 미만 값은 주로 시스템 계정과 서비스가 사용한다. AIX는 대략 6만 5000개나 되는 UID를 제공하므로 바닥날 염려는 없다.
UID나 GID를 변경하는 이유
때때로 UID나 GID를 변경할 필요가 생긴다. 서버나 응용 프로그램을 한 서버에서 다른 서버로 이전하는 경우가 좋은 예다. 또 다른 예로, 관리자가 저지른 실수를 고쳐야 할 경우도 있다. AIX HACMP(High-Availability Cluster Multiprocessing) 환경은 클러스터 내 모든 서버에서 항상 UID와 GID가 똑같아야 한다. 그렇지 않으면 장애복구 기능이 제대로 동작하지 않는다.
UID나 GID를 변경한 결과
AIX에서 UID나 GID를 변경하면 파일 소유권이 달라진다는 사실에 주의해야 한다. UID나 GID를 변경하면 사용자나 그룹이 소유하던 파일은 원래 UID/GID 정수 값이 소유하게 된다(자세한 설명은 아래 예제를 참조한다).
UID 변경
UID와 GID를 변경하는 방법은 두 가지다. smitty를 사용하는 방법과 명령행을 사용하는 방법이다. 아래 예제는 명령행을 사용한다. 명령행 문법은 다음과 같다.
Usage: usermod [ -u uid ] login
|
사용자 bin의 UID를 변경해 보자.
$ grep ^bin /etc/passwd
bin:!:2:2::/bin:
$ usermod -u 5089 bin
$ grep ^bin /etc/passwd
bin:!:5089:2::/bin:
|
usermod 명령을 실행해 시스템 계정 bin의 UID를 2에서 5089로 변경했다. 그러면 bin이 소유하던 파일 전부는 UID 2가 소유하게 된다. AIX는 파일 소유권을 새 UID로 자동 변경하지 않기 때문이다.
다음은 UID를 변경하기 전에 bin이 소유하던 파일이다.
-rw------- 1 bin bin 29 2008-01-19 12:30 tester
|
다음은 UID를 변경한 후다.
-rw------- 1 5089 bin 29 2008-01-19 12:30 tester
|
사용자 bin은 더 이상 파일 tester를 소유하지 않는다. 필요하다면 관리자가 파일 소유자를 bin으로 직접 변경해야 한다. 그래서 UID 변경은 관리자에게 커다란 일거리를 안겨준다.
GID 변경하기
앞서 보았듯이, UID는 변경하기 아주 쉽다. 하지만 뒤따르는 문제가 만만치 않다는 사실도 확인했다. 이 절에서는 명령행에서 GID를 변경해 본다. UID에 비해 GID는 변경하는 과정이 다소 복잡하다. 명령행 문법은 다음과 같다.
Usage: chgroup "attr=value" ... group
|
이제 security라는 그룹의 GID를 변경해 보자.
$grep bduda /etc/passwd
bduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh
$ grep security /etc/group
security:!:350:bduda
$ chgroup "id=7013" security
3004-719 Warning: /usr/bin/chgroup does not update /etc/passwd with the new gid.
$ grep security /etc/group
security:!:7013:bduda
|
GID를 바꾸어도 /etc/passwd 파일에 있는 GID 값은 바뀌지 않는다는 경고가 뜬다. 확인을 위해 직접 passwd 파일을 살펴보자.
$ grep bduda /etc/passwd
bduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh
|
/etc/passwd 파일을 보면 bduda의 기본 그룹은 여전히 350이다. 그러나 security 그룹 GID는 이제 7013이다. 이 문제를 고치려면 다음 명령을 실행한다.
$ chuser "pgrp=security" bduda
$ grep bduda /etc/passwd
bduda:!:300:7013:Ben Duda:/home/bduda:/bin/ksh
|
참고: 위 예제에서는 기본 그룹이 security인 사용자 모두에 대해 chuser 명령을 실행해야 한다. AIX에서 UID와 GID를 변경해도 파일/디렉터리 소유권이 바뀌지 않으므로 직접 변경해야 한다는 사실에 주의한다. 파일 수가 아주 많거나 어느 파일인지 모른다면 상당히 곤란한 상황에 처한다. 다음 절에서는 UID나 GID를 변경하기 전과 변경한 후 파일 소유권을 비교하는 구체적인 예를 다룬다.
파일 소유권 고치기
사용자가 파일을 소유하고 있는 상황에서 사용자의 UID와 GID를 변경할 때 무슨 일이 생기는지 살펴보기 위해 File1과 File2라는 새로운 파일 두 개를 먼저 생성하자.
UID
다음은 이 절에서 살펴볼 예제 파일 두 개다.
$ls -l File*
-rw-r----- 1 bduda security 21 May 19 00:23 File1
-rw-r----- 1 bduda security 23 May 19 00:24 File2
|
파일 소유자는 bduda이고 기본 그룹은 security다. 이제 bduda UID를 변경해 보자.
$usermod -u 34578 bduda
$grep bduda /etc/passwd
bduda:*:34578:7:tester:/tmp/bduda:/usr/bin/ksh
|
이제 UID를 변경했으니 파일 소유권을 살펴보자.
$ls -l File*
-rw-r----- 1 203 security 21 May 19 00:23 File1
-rw-r----- 1 203 security 23 May 19 00:24 File2
|
두 파일 소유자는 203로 바뀌었다. 즉, 변경하기 전 bduda UID 값이다. 따라서 파일 소유권을 원래 주인인 bduda로 바꿔야 한다.
$ chown bduda File*
$ ls -l File*
-rw-r----- 1 bduda security 21 May 19 00:23 File1
-rw-r----- 1 bduda security 23 May 19 00:24 File2
|
만약 사용자가 소유한 파일이 4000개에 이른다면? 파일 소유자를 일일이 고쳐야 한다면?
GID
마찬가지로 다음은 이 절에서 살펴볼 예제 파일 두 개다.
$ls -l File*
-rw-r----- 1 bduda security 21 May 19 00:23 File1
-rw-r----- 1 bduda security 23 May 19 00:24 File2
|
기본 그룹은 security다. 여기서 security GID를 변경해 보자.
$ chgroup "id=7013" security
$grep security /etc/group
security:!:7013:root,bduda
|
이제 GID를 변경했으니 파일 소유 그룹을 살펴보자.
$ls -l File*
-rw-r----- 1 bduda 7 21 May 19 00:23 File1
-rw-r----- 1 bduda 7 23 May 19 00:24 File2
|
두 파일의 기본 그룹은 7이다. 즉, 변경하기 전 security GID 값이다. 따라서 파일 기본 그룹을 원래 그룹인 security로 고쳐야 한다.
$chgrp security File*
$ls -l File*
-rw-r----- 1 bduda security 21 May 19 00:23 File1
-rw-r----- 1 bduda security 23 May 19 00:24 File2
|
만약 UID와 GID를 변경한 후에 파일 소유자를 고치지 않는다면 어떻게 될까? 새로 생성하는 사용자나 그룹이 UID 203이나 GID 7로 만들어진다면, 앞서 bduda와 security가 소유하던 파일 전체를 새 사용자와 새 그룹이 소유하게 된다. 이는 바람직하지 못할 뿐더러 심각한 보안 문제를 초래한다. 다음 절에서는 AIX 시스템에서 소유자가 없는 파일을 찾아본다.
변경 준비 과정: 소유자가 없는 파일 찾기
시스템에서 소유자가 없는 파일을 한번 찾아보자. AIX에서는 간단한 명령으로 가능하다. 사용자가 없는 파일을 모두 찾으려면 명령행에서 다음 명령을 실행한다.
find / \( -fstype jfs -o -fstype jfs2 \) -nouser -print
|
파일 시스템을 설정한 방식에 따라 위 명령은 NFS로 마운트된 디렉터리를 제외하고 전체 시스템을 검색한다. 소유 그룹이 없는 파일도 같은 방식으로 찾는다.
find / \( -fstype jfs -o -fstype jfs2 \) -nogroup -print
|
소유자나 소유 그룹이 없는 파일을 찾아냈다면 이제 절반 정도 전진한 셈이다. 다음으로, 소유자가 누구인지 그리고 어느 그룹에 속해야 하는지 파악해야 한다. 시스템 관리자 입장에서 쉽지 않은 일이다. 일단은 사용자나 그룹 디렉터리를 살펴보라고 권한다. 이 디렉터리를 참조하여 소유자와 소유 그룹을 결정한다. 그래도 결정하기 어렵다면 사용자와 그룹을 root로 지정하는 방법도 나쁘지 않다.
각자 환경에서 UID와 GID 일관성 유지하기
유닉스를 사용하는 대다수 회사는 서버를 여러 대 돌린다. 여러 서버에서 같은 프로세스를 실행한다면 사내 서버 모두가 동일한 UID와 GID를 사용하는 편이 좋다. 중앙에서 사용자를 관리한다면 UID와 GID가 이미 동일하므로 IBM HACMP를 구축하기가 훨씬 쉬워진다.
예를 들어, IBM DB2® Universal
Database™를 사용하는 응용 프로그램이 있다고 치자. AIX HA 쌍에서 돌아가는 아주 중요한 프로그램이다. 두 서버는 어느 쪽이 주 서버이고 어느 쪽이 부 서버인지에 따라 파일 시스템을 주고 받는다. 주 서버에서 DB2 데이터베이스를 돌리는 계정 UID는 300이다.
표준적인 동작 시나리오를 대상으로 만약 주 서버가 장애를 일으켰다고 가정하자. 그러면 주 서버가 하던 일을 부 서버가 수행하기 시작한다. 그런데 부 서버에서 DB2 데이터베이스를 돌리는 계정 UID가 400이라면 심각한 문제가 발생한다. 주 서버 파일 시스템에 있는 파일은 UID가 300인 DB2 계정이 생성했다. 하지만 부 서버가 작업을 수행하면 파일 소유권에 문제가 생긴다. UID가 400인 DB2 계정이 UID가 300으로 만들어진 DB2 파일을 소유하지 않기 때문이다. 데이터베이스가 파일을 소유하지 않으므로 HA가 작동하더라도 응용 프로그램은 제대로 동작하지 못한다.
때로는 파일 수가 너무 많아 일일이 고치기가 불가능하다. 이런 상황에서 스크립트가 편리하다.
스크립트 짜기
4만 개에 이르는 파일 소유자를 한 번에 하나씩 고친다고 상상해 보라. 다행스럽게도 파일을 모두 찾아내는 방법은 이미 안다. 여기에 스크립트를 조금만 추가하면 소유자와 소유 그룹도 쉽게 고칠 수 있다.
보통 파일 시스템 전체를 검색하려면 상당한 시간이 걸린다. 이 때 펄을 사용하면 시간이 크게 단축된다. 펄이 제공하는 find2perl이라는 명령은 일반 AIX find 명령을 펄 코드로 바꿔준다. 이 코드는 일반 유닉스 find 명령보다 빠르게 파일 시스템을 검색한다.
$find2perl / \( -fstype jfs -o -fstype jfs2 \) -nouser -print > find_owner_script.pl
$find2perl / \( -fstype jfs -o -fstype jfs2 \) -nogroup -print > find_group_script.pl
|
펄을 설치하지 않았다면 일반 find 명령을 사용해도 좋다.
$find / \( -fstype jfs -o -fstype jfs2 \) -nouser -print > find_owner_script.txt
$find / \( -fstype jfs -o -fstype jfs2 \) -nogroup -print > find_group_script.txt
|
이제 자동으로 펄 스크립트를 만들었다. 이 스크립트는 시스템에서 소유자가 없는 파일을 모두 찾아 화면에 출력한다. 원한다면 스크립트를 수정하여 파일로 출력해도 좋다.
이제 파일이 속할 소유자와 소유 그룹을 결정한 후 변경할 차례다. 다음 절을 살펴보자.
소유자 스크립트
명령행에서 다음을 입력하거나 코드를 스크립트에 추가한다.
$ for file in $(cat output_from_find_owner_script.pl)
do
print "Old permissions: $(ls -l $file)" >> /tmp/UID_LOG
chown $new_owner $file
print "New permissions: $(ls -l $file) >> /tmp/UID_LOG
done
|
결과는 다음과 같다.
Old permissions: -rw------- 1 485 bin 29 2008-01-19 12:30 tester
New permissions: -rw------- 1 bin bin 29 2008-01-19 12:30 tester
Old permissions: -rw------- 1 987 bin 4098 2008-01-26 12:30 host
New permissions: -rw------- 1 bin bin 4089 2008-01-26 12:30 host
|
그룹 스크립트
그룹도 유사한 단계를 거친다.
$for file in $(cat output_from_find_group_script.pl)
do
print "Old permissions: $(ls -l $file)" >> /tmp/GID_LOG
chgrp $new_group $file
print "New permissions: $(ls -l $file) >> /tmp/GID_LOG
done
|
결과는 다음과 같다.
Old permissions: -rw------- 1 765 bin 29 2008-01-19 12:30 passwd
New permissions: -rw------- 1 root bin 29 2008-01-19 12:30 passwd
Old permissions: -rw------- 1 983 bin 4098 2008-01-26 12:30 group
New permissions: -rw------- 1 root bin 4089 2008-01-26 12:30 group
|
위 예제는 파일 소유자와 소유 그룹을 변경하기 전과 변경한 후 파일 상태를 로그 파일에 기록한다. 필요하다면 로그 파일을 살펴 스크립트가 올바로 동작하는지 확인한다.
결론
유닉스에서 UID와 GID가 동작하는 방식을 이해하기가 만만치 않다. UID나 GID를 변경할 일이 생긴다면 변경이 초래하는 결과를 정확히 이해해야 한다. 그렇지 않으면 시스템을 심각한 위험에 빠뜨릴 수도 있다. 그런 다음, 필요하다면 스크립트를 이용하여 UID나 GID 문제를 손쉽게 해결하면 되겠다.
참고자료 교육
제품 및 기술 얻기
-
IBM 평가판 소프트웨어: DB2®, Lotus®, Rational®, Tivoli, WebSphere® 등과 같은 응용 프로그램 개발 도구와 미들웨어 제품을 다운로드 받아 사용해보자.
토론
필자소개 | | | Kurt Riley는 2000년부터 유닉스와 리눅스 환경에서 일했으며, 포춘(Fortune) 500대 기업 여러 곳에 컨설팅 서비스를 제공한다. 정보 기술학 석사 학위를 소지한 그는 현재 월풀 사에서 Tivoli 보안 제품을 지원하고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
