setUID, setGID, sticky bit 세 가지의 특수 권한이 존재한다.
지금까지 권한 파트에서 살펴본 내용은 모두 일반 권한에 대한 내용이다.
이번 포스팅에서는 setUID, setGID, sticky bit 세 가지의 특수 권한에 대해 알아본다.
특수 권한은 일반 권한과 비교했을 때 다소 특이한 동작을 하며, 각 영역의 x가 s나 t로 바뀐다.
숫자로 변환하면 일반 권한 숫자 값의 앞에 각각 4, 2, 1이 추가로 붙는다.
1) setUID
- Owner 영역의 x가 s로 바뀌는 경우
- 4777
- r w s r w x r w x
2) setGID
- Group 영역의 x가 s로 바뀌는 경우
- 2777
- r w x r w s r w x
3) sticky bit
- Other 영역의 x가 t로 바뀌는 경우
- 1777
- r w x r w x r w t
* x 위치의 문자 s/t로 변경 시
x가 있는 상태였다면 소문자 s/t 사용
x가 없는 상태였다면 대문자 S/T 사용
ex)
r w x r - x r - x → r w s r - x r - x : 4755 (Owner 영역에 x가 있는 상태)
r w - r - x r - x → r w S r - x r - x : 4655 (Owner 영역에 x가 없는 상태)
sticky bit
sticky bit은 디렉토리에 설정하는 특수 권한이다.
디렉토리 내부의 파일/디렉토리 생성은 권한만 있으면 누구나 가능하지만,
파일/디렉토리의 삭제는 대상의 소유자(소유권의 UID)와 관리자만 가능하다.
root 계정에서 user1 사용자와 /sb 디렉토리를 생성해준 후,
itbank 사용자와 user1 사용자로 로그인 한 두 개의 창을 추가로 띄워주고 실습을 해보자.

현재 상태에서 itbank 사용자로 /sb 내부에 파일 생성을 시도해도 만들어지지 않는다.
/sb의 Other 영역에 w 권한을 추가해주면(권한값 757) itbank 사용자로 파일 생성이 가능하다.
Other 영역의 권한을 변경한 이유는 itbank와 /sb의 UID, GID가 모두 다르기 때문이다.

/sb 디렉토리 자체에 w 권한이 생겨 user1 사용자도 itbank 사용자가 만든 파일을 지울 수 있다.

지금까지는 sticky bit 권한을 설정하지 않았다.
따라서 디렉토리에 일반 권한만 있으면 어떤 사용자든지 내부에 파일을 생성/삭제할 수 있다.
이번에는 root 계정으로 /sb 디렉토리의 권한을 sticky bit 권한으로 변경해준다.
itbank로 /sb/c 파일을 생성한 후 user1로 해당 파일의 삭제를 시도하면 지워지지 않는다.

sticky bit 권한 설정 시, 생성은 권한만 있으면 누구나 할 수 있지만, 삭제는 소유자만 가능하다.
아래 화면에 보이는대로 파일 c의 소유권이 itbank에게 있기 때문에 user1은 c를 삭제할 수 없다.
소유자와 관리자만 삭제할 수 있으므로, itbank와 root로는 파일 삭제가 가능하다.

다음 실습을 위해 user1 접속을 닫은 후 /sb 디렉토리와 user1 사용자를 지워준다.
itbank는 접속된 상태로 남겨둔다.

setUID
setUID는 실행 파일에 설정하는 특수 권한으로,
파일이 동작하는 동안 Owner(= 소유자)의 권한을 사용할 수 있도록 해준다.

비밀번호를 변경할 때 사용하는 명령어 passwd의 실행 파일은 /usr/bin/passwd이다.
이 파일의 권한을 바꿔가면서 passwd 명령이 실행되는지 확인하는 실습을 해보려고 한다.
root 계정으로는 권한 변경만 해주고, itbank 사용자로 자기 자신의 암호를 바꾼다.

(풀이)
허가권 명령 실행 비밀번호 변경
4755 o o
755 o x
4750 x x
* 권한은 항상 숫자가 아닌 문자로 봐야 의미가 있다.
(1) 4755
r w s r - x r - x
setUID가 걸려있기 때문에 Owner의 권한을 빌려서 사용할 수 있다.
따라서 root 권한으로 인증 토큰 수정과 비밀번호 변경이 가능하다.
(2) 755
r w x r - x r - x
setUID가 걸려있지 않아 관리자 권한을 받지 못하고 인증 토큰 수정이 불가능하다.
(3) 4750
r w s r - x - - -
Other 영역에 파일 실행 권한인 x 권한이 없어 명령어 실행조차 불가능하다.

umask
umask는 생성되는 파일과 디렉토리의 허가권을 제어하는 값이다.
사용자 계정마다 특정한 값이 부여되어 있으며, 허가권 값은 아래와 같이 계산한다.
참고하자면 소유권은 생성 작업을 수행하는 사용자의 UID, GID로 설정된다.
만들어지는 파일/디렉토리의 허가권 값
= (파일/디렉토리의 기본적인 최대 권한값) - (생성 작업을 입력한 사용자의 umask 값)
* 파일은 666, 디렉토리는 777이 최대 권한 값이다.
umask 사용 실습
root 계정과 itbank 계정에서 아래와 같이 파일 f1, f2와 디렉토리 d1, d2를 생성해준다.
umask를 입력하면 root는 0022, itbank는 0002로 서로 다른 값을 가지는 것을 확인할 수 있다.

f1, f2, d1, d2 각각의 허가권 값은 아래와 같은 계산 과정을 거쳐 결정된다.

단, 숫자로 표현된 권한값만을 가지고 계산해서는 안된다.
모든 권한값은 문자로 변환해주고 살펴보는 것이 정확하다.

위의 예시를 보면 파일을 생성할 때 기본 최댓값 666에서 umask 값 003을 빼주었지만,
연산 결과로 나온 허가권 값은 663이 아닌 664이다.
umask 값에 x가 존재하더라도 파일의 기본 권한에는 x가 없기 때문에 계산하지 않는다.
실제로 itbank 사용자의 umask 값을 003으로 변경한 뒤 확인해보면 664의 권한값이 나온다.

확인 후 umask 값은 다시 002로 돌려놓는다.
권한을 숫자로 표현하는 것은 단순히 보기 편하기 위해서이며,
권한값을 숫자로 계산해서는 안되고 숫자로 되어 있더라도 항상 문자로 변환해서 봐야 한다.
사용자 홈 디렉토리 복구
이전 포스팅에서 사용자 홈 디렉토리를 복구하는 간단한 팁을 알아본 적이 있다.
홈 디렉토리가 손상되기 이전의 snapshot을 찾아 이동하는 방식이다.
이번에는 권한을 사용하여 정석으로 홈 디렉토리를 복구하는 방법을 알아보려고 한다.
기본적으로 사용자 홈 디렉토리 자체 권한의 경우 허가권은 700으로,
소유권은 사용자의 UID, GID와 같은 값으로 설정되어야 한다.

임의로 ~itbank 디렉토리를 삭제하고, /etc/skel 디렉토리를 /home/itbank 위치에 복사해준다.
같은 위치에 같은 이름으로 복사가 되었다고 홈 디렉토리의 역할을 하지는 않는다.
사용자 홈 디렉토리의 역할을 하기 위해서는 권한값을 변경해주어야 한다.
앞에서 언급한대로 chmod 700 ~itbank로 홈 디렉토리의 허가권 값을 700에,
chown -R itbank. ~itbank로 소유권을 itbank 사용자의 UID, GID에 맞춰준다.
chown에 -R 옵션을 사용한 것은 하위 파일/디렉토리의 소유권을 한 번에 변경해주기 위해서다.
허가권은 사용자 홈 디렉토리 자체의 권한만 건드리면 되지만,
소유권은 홈 디렉토리 하위의 파일과 디렉토리의 권한까지 바꿔주어야 한다.
이렇게 권한 파트가 모두 마무리되었다.
다음 포스팅에서는 프로그램의 설치, 삭제, 관리와 관련된 내용을 다룬다.
'2022 데이터 사이언스 > Linux' 카테고리의 다른 글
19. 프로그램 설치(2): rpm (0) | 2022.05.31 |
---|---|
18. 프로그램 설치(1): tar (0) | 2022.05.31 |
16. 권한(3): 소유권과 권한 적용 (0) | 2022.05.30 |
15. 권한(2): 웹 서버와 http (0) | 2022.05.30 |
14. 권한(1): 허가권 (0) | 2022.05.29 |