Unix 나 Linux 의 파일시스템의 허가권(permission).. 별 것 아니라고 생각하겠지만, 의외로 잘 모르는 것들이 있다.
일단 누구나 다 아는 얘기 먼저. ls -l 로 알 수 있는 화일의 정보는 다음과 같다.
+--------- 화일의 소유자가 이 화일을 읽을 수 있는가
|+-------- 화일의 소유자가 이 화일에 기록할 수 있는가
||+------- 화일의 소유자가 이 화일을 실행할 수 있는가
|||
|||+------ 화일과 같은 그룹ID 에 속한 이들이 이 화일을 읽을 수 있는가
||||+----- 화일과 같은 그룹ID 에 속한 이들이 이 화일에 기록할 수 있는가
|||||+---- 화일과 같은 그룹ID 에 속한 이들이 이 화일을 실행할 수 있는가
||||||
||||||+--- 타인이 이 화일을 읽을 수 있는가
|||||||+-- 타인이 이 화일에 기록할 수 있는가
||||||||+- 타인이 이 화일을 실행할 수 있는가 +- 화일의 크기 +- 화일 이름
||||||||| | |
-rwxrwxrwx 2 anonymous anonymous 30 Jul 23 18:10 myfile
| | | | |
| | | +- 화일의 그룹ID |
+- - : 일반화일 | +- 화일의 소유자ID |
d : 디렉토리 | +- 최근 수정 시각
b : 블럭장치 +- 하드링크의 갯수
c : 문자장치
l : 심볼릭링크
"또똥눠"라는 사용자가, 디렉토리를 하나 만들고, 그 디렉토리 안에 자신의 화일을 하나 만들었다. 또똥눠는 그 화일을 타인이 건드리는 것을 원하지 않았고, 다음과 같이 허가권을 설정하였다. 다만 디렉토리는 여러 사람들이 공용으로 사용하도록 하기 위하여 허가권을 777을 주었다.
drwxrwxrwx 2 또똥눠 또똥눠 4096 10월 24 11:48 또똥눠의디렉토리/
-rw------- 1 또똥눠 또똥눠 132 10월 24 11:48 또똥눠의디렉토리/중요한화일
이 때, 평소에 또똥눠가 너무 자주 화장실을 점유하는 것에 반감을 가지고 있던 룸메이트 "그만눠"가 이 시스템에 로긴했고, 또똥눠가 화장실에 간 사이에 그를 괴롭히기 위해 또똥눠의 "중요한화일"을 삭제하기로 맘을 먹었다. 그만눠는 과연 성공할 수 있을 것인가?
정답은 "yes". 그렇다면 방법은? 별 것 없다. 그냥 "rm 중요한화일" 하면 된다.
$ ls -l
total 4
-rw------- 1 또똥눠 또똥눠 132 Oct 24 11:48 중요한화일
$ cat 중요한화일
cat: 중요한화일: Permission denied
$ rm 중요한화일
rm: remove write-protected file `중요한화일'? y
$ ls
$
허가권이 600 으로 설정되어 있기 때문에 그만눠는 중요한화일을 읽을 수도, 쓸 수도 없다. 그렇지만, 그는 중요한화일을 삭제할 수는 있다. 왜냐하면, "또똥눠의디렉토리"의 퍼미션이 777 이고, 타인이 write 하는 것을 허용하는 퍼미션이기 때문이다.
명심하라. 화일의 삭제가 가능한지의 여부는, 화일의 허가권이 아니라 그 화일이 존재하는 디렉토리의 쓰기허가권(write permission)에 의해 결정된다. ext2 등의 화일시스템에서는, 화일의 생성 또는 삭제는 디렉토리의 "내용"을 변경하는 것과 동일한 개념이기 때문이다.
그만눠의 만행으로 중요한화일을 잃어버린 또똥눠는 대책을 강구하기로 하였다. 가장 좋은 해결책은 물론 디렉토리 퍼미션을 700, 하다못해 755 정도로 하여 타인이 그 디렉토리 안에서 화일을 생성하거나 삭제하지 못하는 것이지만, 위에서 말했듯이 공용으로 사용을 해야 될 사정이 있어서 그러지는 못한다. 이럴 때 사용하는 해결책이 sticky bit. 즉 디렉토리 허가권을 1777, rwxrwxrxt로 만드는 것이다. sticky bit 가 붙어 있는 디렉토리 아래서는 자기 소유가 아닌 화일을 삭제하지 못한다. 이 역시 알 사람은 다 아는 얘기.
다음 날, 디렉토리를 들여다 본 또똥눠는, 새로운 화일이 생겨난 것을 발견하였다.
$ ls -l
drwxrwxrwt 2 또똥눠 또똥눠 4096 10월 24 13:46 또똥눠의디렉토리/
-rw-r--r-- 1 그만눠 그만눠 113 10월 24 13:46 또똥눠의디렉토리/그만눠의화일
그만눠의 이름을 보는 순간 어제 당한 일을 생각하고 이성을 잃은 또똥눠는, 복수를 하기로 결심하였다. 또똥눠 역시 그만눠의 화일을 삭제하고자 한다. 그러나 이 디렉토리에는 sticky bit 가 붙어 있다. 또똥눠는 어떻게 해야 할 것인가?
역시 답은, 그냥 "rm 그만눠의화일" 하면 된다.
$ rm 그만눠의화일
rm: remove write-protected file `그만눠의화일'? y
$ ls
$
또 한 번 명심하라. sticky bit 가 붙은 디렉토리라 하더라도, 그 디렉토리의 소유자라면 디렉토리 안에 있는 타인의 화일들을 삭제할 수 있다 sticky bit 때문에 그만눠는 또똥눠의 화일을 삭제할 수 없다. 그러나 또똥눠는 자신이 소유자인 디렉토리 안에 있는 그만눠의 화일을 얼마든지 삭제할 수 있는 것이다. (삭제하지 못한다 하더라도 별 의미는 없다. 퍼미션을 슬쩍 777로 바꾼 후에 삭제하면 그만이니까)
이 사실이 평소에 와닿지 않는 이유는 - 짐작일 뿐이지만 - sticky bit 가 붙은 대표적인 디렉토리가 /tmp 이고, /tmp 는 root 의 소유이기 때문이 아닐까. /tmp 안에 있는 일반 유저들의 화일을 root 가 삭제해도, root 라서 그럴 수 있는 것이려니 하고 말지 sticky bit 가 다른 일반 유저로부터 자신의 화일을 보호해준다는 것 자체에는 추호의 의심도 하지 않게 되는 것이다.
디렉토리의 파일 리스트를 보기 위해서도 그 디렉토리의 퍼미션은 읽기가능 (4 이상) 으로 설정되어 있어야 한다. 이게 가슴에 와 닿을 때는 익숙하지 않은 툴로 스크립트를 작성하다 이 문제에 맞닥뜨렸을 때다. 결과가 나오지 않는 것이 퍼미션 때문이라고는 추호도 생각하지 않고, 자신의 스크립트 실력을 탓하게 된다.
디버깅을 할 때에는 자신의 프로그램이 완벽하다는 가정을 한번씩 해 볼 필요가 있다. - danny
이왕 말이 나왔으니 조금 더 하면... 디렉토리의 경우 "읽기권한만 있고 실행권한이 없는 경우" (444 등) 에는 디렉토리에 들어 있는 화일의 목록만 볼 수 있을 뿐, 화일의 구체적인 정보라던가 화일의 내용을 읽을 수는 없다. (즉 디렉토리의 내용을 읽는 것이다.) 이 퍼미션은 거의 의미가 없다. 반대로 "읽기권한은 없고 실행권한만 있는 경우" (111 등) 에는 디렉토리에 들어 있는 화일의 목록은 볼 수 없지만, 화일의 내용은 볼 수 있다. (화일의 퍼미션에 따라서 쓰거나 실행도 할 수 있겠다.) 목록을 볼 수 없는데 어찌 화일의 이름을 아느냐.. 화일의 주인이 알려 주면 된다.
그런 이유에서, 자기의 홈페이지 디렉토리나 홈디렉토리 등의 퍼미션은 755 가 아니라 711 이 바람직하다. public_html 디렉토리의 퍼미션이 711 이면, 홈페이지 주인이 명시적으로 링크를 만들어둔 화일만 볼 수 있다. 읽거 퍼미션을 주어야 할 때도 가끔은 있다.
가장 큰 문제는 게시판, 방명록 등 CGI 를 사용할 때이다. CGI 의 원리는 한 마디로, 웹브라우저에서 글쓰기 버튼을 누르면, 홈페이지에 있는 특정한 프로그램이 실행되고, 그 프로그램이 작성된 내용을 홈페이지 디렉토리 안에 적절히 저장하고, 그것을 html 의 형식으로 웹브라우저로 다시 보내주는 것이다. 그런데, 이때 실행되는 프로그램은, 홈페이지 주인의 권한이 아니라, 제 3자, 즉 웹서버의 권한으로 실행된다. (시스템에 따라 다르나, 주로 www, apache, www-data, nobody 등의 userID 를 갖는다)
이 CGI 프로그램이 홈페이지의 내용을 수정하거나 새로운 화일을 만들거나 삭제해야 한다. 따라서 퍼미션의 마지막 세 비트가 111(2) = 7(8) 이 되어야 한다. 게시판 설치 문서를 보면 디렉토리 퍼미션을 777 로 해 주라는 이유가 그것이다. 말을 바꾸면, 시스템에 로긴한 다른 사람이 해당 디렉토리의 이름을 유추할 수 있다면 그 디렉토리까지 한 번에 접근하여 화일을 삭제해 버릴 수 있다는 건데.. 해결책은? 글쎄... 해 보지는 않았지만 sticky bit 를 붙이는 것도 하나의 방법이 될 수 있겠다. 이에 대한 보완책을 아는 이들의 아낌없는 협조를 바람. -raymundo
컴퓨터분류