: kldp를 포함해서 제가 아는 모든 리눅스 게시판을 다 뒤져봤는데
: setuid라는 무저열은 잇는데 그게 무엇인지 설명된 글이 하나도 없더군요
: 심지어 제가 가진 두권의 리눅스 책에도 없었습니다
: setuid가 무슨말인지 가르쳐주세요
유닉스 스타일(ftp 라면 윈도NT 계열도 마찬가지겠지만)에서는 각 파일에 대한 접근 권한이
설정됩니다. r 은 파일을 읽을 수 있는 권한을, w 는 파일의 수정 권한, x 는 실행권한을 의
미합니다. 다음과 같은 파일이 살펴 보지요.
$ ls -l test.txt
-rw-r--r-- 1 checks dev 0 12월 4일 12:49 test.txt
파일 권한에 관련된 내용인, -rw-r--r-- 에서 맨 처음 하이픈(-)은 test.txt 가 파일임을 알려 줍
니다. 디렉토리라면 (-) 대신 d 가 표시가 됩니다.
그리고 나머지 아홉개의 문자는 각각 3개씩 끊어서 파일소유자, 그룹, 일반(그룹에 소속되
지 않은 다른 사람)에 대한 권한을 나타내지요. 그리고 세번째, 네번째에 씌여져 있는 checks
는 test.txt 파일의 소유자임을 나타내고, dev는 접근할 수 있는 그룹을 의미합니다. 여기까
지는 일반적인 파일 접근입니다. (이걸 보통 DAC 이라고 부른다고 합니다.)
이 내용으로 알 수 있는것은 checks 라는 사람에게는 읽기 쓰기 권한이 부여가 되고, dev 그룹
에 속한 사람과 그 외 다른 사람은 수정권한은 가질 수없습니다. test.txt 가 실행할 수 있는
파일이고, 실행권한까지 부여가 되어 있다면 -rwxr-xr-- 1 checks dev 0 12월 4
일 12:49 test.txt 즉, 위와 같이 되어 있다면 test.txt를 실행할 수 있는 사람은 checks 계정을
가진 사람과 dev 그룹입니다. 한개의 프로세스가 실행할때는 프로세스를 실행하는 사람의
속성을 따르게 됩니다. test.txt는 checks 만이 실행할 수 있으며 checks가 실행시켰기 때문에 프
로세스는 checks가 가진 권한을 상속 받아서 프로세스가 작동됩니다. 또 neo 라는 사용자가 de
v 그룹에 속해 있다면 neo도 test.txt 파일을 실행 시킬 수 있습니다. 이때는 당연히 neo 사용자
의 권한을 test.txt가 상속을 받지요. 이제 먼저 물어 봤던 setuid를 살펴보지요.
setuid는 프로세스 실행시에 특정 계정(ID)의 속성으로 권한을 바꾸게 됩니다.
setuid 설정이 되어 있는 것은 x 대신에 s로 표시가 됩니다.
-rwsr-xr-- 1 checks dev 0 12월 4일 12:49 test.txt
위와 같이 된다면 checks 가 실행시키든, dev 그룹에 속한 neo가 실행시키든 test.txt 가 실행될
때의 속성은 checks 계정이 가진 속성을 따르게 됩니다. 대표적인 setuid 프로그램(?)은 passwd
가 있습니다. 아시다 시피 passwd 는 계정의 비밀번호를 바꿀때 사용합니다.
passwd 프로그램이 접근하는 파일은 /etc/passwd 파일인데 이 파일의 속성은 다음과 같습니다.
-r--r--r-- 1 root sys 512 12월 3일 17:38 /etc/passwd
(위에 내용중에서 그룹인 sys는 시스템에 따라서 다릅니다.또, 파일의 쓰기 권한이 소유자
에 대해서 허가되어 있는 경우도 있긴 합니다.) 위 내용을 보면.. 일반 사용자(sys에도 포함
되지 않은)은 읽기는 가능하긴 하지만 수정할 권한을 가지지 못합니다. 이런 경우라면 자
신의 비밀번호를 바꾸지도 못할텐데 이것을 해결하기 위해서 passwd 프로그램(/usr/bin/passwd
를 말합니다.)은 setuid 설정이 되어 있지요. -r-sr--r-x 3 root sys 101744 2000년 1월
6일 /usr/bin/passwd 즉, 일반 사용자도 실행할 수 있는 권한(r-x)을 가지고 있으므로 일단 실
행은 가능하게 되고, 실행한 이후는 setuid 속성을 가지기 때문에(r-s) 실행되는 순간에는 pass
wd 프로그램의 소유자인 root의 권한을 가지게 됩니다. root의 권한을 가지고 있는 상태이기
때문에 /etc/passwd 파일을 수정할 수 있지요. setuid가 임시로 특정 사용자의 권한을 부여하는
편리함을 가지고 있지만 해킹에 대한 헛점이 있다고 합니다. 즉, setuid로 실행된 순간에 정
상적인 경우라면 작업 종료후에 원래의 계정으로 권한이 돌아와야 하는데(사용자 쉘로 전
환되야 한다고 합니다.) 그렇지 못하게 되면 순간적으로 프로세스의 소유자 쉘로 떨어지는
경우가 있습니다. 보통 setuid 를 설정하는 경우는 대부분 root 권한을 임시적으로 사용하는
경우가 많기 때문에, "root 권한 획득"은 setuid를 이용한 경우가 있습니다. (그 외에 다른 것
도 있지만 대부분 그렇더군요.)--눈이 오면 길만 막힌다.