権限はファイルではなくプロセスに付く

한 줄 요약

리눅스의 접근 제어는 "이 파일을 누가 읽을 수 있는가" 가 아니라 "지금 이 프로세스가 들고 있는 자격증명이 이 inode 의 권한 비트와 어떻게 맞아떨어지는가" 로 판정된다. 이 관점을 잡으면 setgid 디렉터리도 ACL 마스크도 자연스럽게 이해된다.

왜 이게 필요했나

사용자를 그룹에 추가했는데 권한이 안 생긴다는 문의가 끊이지 않는다. 원인은 대부분 하나다. 보조 그룹은 로그인 시점에 프로세스의 자격증명으로 복사된다. 이미 떠 있는 셸은 예전 그룹 목록을 그대로 들고 있고, 파일 접근 판정은 그 목록으로 이뤄진다. 그룹을 바꿨으면 다시 로그인하거나 새 세션을 열어야 한다.

/etc/passwd 는 이름과 UID, GID, 홈, 셸을 담고, 암호 관련 정보는 전부 /etc/shadow 로 분리돼 있다. 분리된 이유는 단순하다 — /etc/passwd 는 모두가 읽을 수 있어야 ls -l 이 UID 를 이름으로 바꿔 보여 줄 수 있지만, 해시는 그러면 안 되기 때문이다.

/etc/shadow 의 필드는 콜론으로 나뉜다.

번호	내용
2	암호 해시. 맨 앞의 느낌표는 잠김, 별표는 암호 로그인 불가
3	마지막 암호 변경일 (1970-01-01 부터의 일수)
4	최소 사용 일수
5	최대 사용 일수
6	만료 전 경고 일수
8	계정 만료일 (역시 일수)

날짜가 아니라 일수라는 점이 시험에서 자주 나온다. 사람이 읽을 형태로 바꿔 주는 것은 chage -l 이다.

어떻게 동작하나

setgid 디렉터리가 협업 디렉터리의 정답인 이유. 새로 만든 파일의 그룹은 보통 만든 사람의 기본 그룹이 된다. 팀원 세 명의 기본 그룹이 각자 다르면 공유 디렉터리에 파일이 제각각의 그룹으로 쌓인다. 디렉터리에 setgid 를 세워 두면 그 안에서 만들어진 파일이 디렉터리의 그룹을 물려받는다. 새 하위 디렉터리는 setgid 비트까지 물려받아 트리 전체가 유지된다.

sticky 비트는 삭제 권한을 되찾아 온다. 파일을 지우는 데 필요한 것은 그 파일이 아니라 그 디렉터리에 대한 쓰기 권한이다. 공유 디렉터리를 모두에게 쓰기 가능하게 열면 남의 파일도 지울 수 있게 된다. sticky 를 세우면 소유자와 디렉터리 소유자, root 만 지울 수 있다. /tmp 가 정확히 이 구성이다.

ACL 이 필요한 순간은 '한 명만 예외' 일 때다. 소유자·그룹·기타 세 칸으로는 "이 그룹은 읽기, 그런데 감사 담당자 한 명은 쓰기" 를 표현할 수 없다. 그룹을 새로 파는 대신 명명된 항목을 붙이는 것이 ACL 이다.

여기서 마스크가 등장한다. 마스크는 소유자와 기타를 제외한 모든 항목(명명된 사용자, 명명된 그룹, 그룹 소유자)의 권한 상한이다. getfacl 이 #effective: 를 붙여 보여 주는 줄이 바로 마스크에 깎인 항목이다. 그리고 함정이 하나 있다 — 파일에 chmod 를 걸면 그 그룹 비트가 마스크로 해석되어, 방금 준 ACL 이 조용히 무력해진다.

디렉터리에는 default ACL 을 걸 수 있다. 이것은 그 디렉터리 자체의 접근 판정에 쓰이지 않고, 앞으로 그 안에 만들어질 항목의 초기 ACL 로 상속된다.

현장에서 만나는 모습

저자의 파일 디스크립터·inode 글에는 이 문제가 한 문장으로 정리돼 있다. 파일에 대한 쓰기 권한과 삭제 권한은 별개이며, 공유 디렉터리에서 남의 파일이 지워지는 사고가 바로 여기서 나온다. 그 글이 제시하는 표준 해법이 chmod 1777 — 즉 sticky 비트다. 반대로 setgid 없이 공유 디렉터리를 운영하면, 파일마다 그룹이 달라져 나중에 일괄로 chgrp -R 를 돌리는 정리 작업이 주기적으로 생긴다.

계정 쪽에서 가장 비싼 실수는 보조 그룹을 더할 때 추가 옵션을 빠뜨리는 것이다. usermod -G 만 쓰면 기존 보조 그룹이 전부 지정한 목록으로 대체된다. sudo 그룹에서 자기 자신을 빼 버리고 root 셸도 없는 상태가 되면 그때부터는 콘솔 접근 문제로 바뀐다.

시험장에서 자주 걸리는 권한 문제

LFCS 는 실기라 "설명할 수 있다" 가 아니라 "손이 기억한다" 를 묻는다. 권한 영역에서 반복해서 나오는 형태가 몇 가지 있다.

특수 비트 셋은 숫자 앞자리로 붙는다.

비트	숫자	파일에서	디렉터리에서
setuid	4000	소유자 권한으로 실행	(의미 없음)
setgid	2000	그룹 권한으로 실행	새 파일이 그 디렉터리의 그룹을 물려받는다
sticky	1000	(의미 없음)	소유자만 자기 파일을 지울 수 있다(/tmp)

협업 디렉터리 문제는 거의 언제나 setgid 다. "팀원 누구나 읽고 쓸 수 있게" 라는 요구는 chgrp team dir; chmod 2775 dir 로 푼다. setgid 가 없으면 새 파일이 만든 사람의 기본 그룹을 갖게 되어 다른 팀원이 못 읽는다.

ACL 은 기본(default) ACL 을 함께 걸어야 한다. 지금 있는 파일에만 걸면 나중에 만들어지는 파일에는 적용되지 않는다.

setfacl -m u:alice:rwx /srv/data          # 지금 있는 것
setfacl -d -m u:alice:rwx /srv/data       # 앞으로 만들어질 것
getfacl /srv/data

ls -l 에서 권한 끝에 + 가 보이면 ACL 이 걸려 있다는 뜻이다. 이것을 놓치면 "권한이 맞는데 왜 안 되지" 를 오래 헤맨다.

umask 는 앞으로 만들 것에만 적용된다. 이미 있는 파일은 chmod 로 고쳐야 한다. 반대로 "앞으로 만드는 파일도 그렇게 되게" 라는 요구에 chmod 로 답하면 틀린다.

사용자를 지울 때 홈과 메일 큐를 어떻게 할지 묻는다. userdel -r 은 홈 디렉터리까지 지운다. 지우지 않으면 그 UID 가 재사용될 때 새 사용자가 옛 파일을 소유하게 된다. 그래서 지우지 않을 것이라면 소유권을 먼저 옮긴다.

바꾼 뒤 반드시 확인한다. id 사용자, groups 사용자, sudo -l -U 사용자 세 줄이면 대부분의 설정 문제가 드러난다.

다음 실습에서 할 것

먼저 실제로 사용자와 그룹을 만든다. UID·기본 그룹·홈·셸을 지정해 계정을 세우고, 보조 그룹을 더하고, chage 로 암호 정책을 걸고, /etc/passwd·/etc/group·/etc/shadow 에서 그 값을 직접 읽어 확인한다. 마지막에는 계정만 지우고 홈을 남겨 고아 UID 가 생기는 모습을 본다. 이어지는 실습에서는 8진수와 기호 모드, umask, 특수 비트, ACL 과 마스크를 차례로 다룬다.