setuid setgid 매우 자세하게!

안녕하세요 마무입니다~ 오늘은 리눅스 권한의 연장선상에 있는 개념 "리눅스 특수권한"과
"setuid", "stickybit", "setuid"에 대해 알아보겠습니다!

이 포스트를 다 읽으시면

setuid setgid stickybit 개념을 확실히 알고 사용하실 수 있으실 겁니다

최대한 쉽게 설명하려고 노력할 테니 화이팅해서 오늘도 공부해보자구요!

***이 포스트를 이해하기 위해 알고있어야 할 개념들***
1. inode 개념
2. 유저, 그룹, other의 개념
3. rwx, 권한 개념
***********************************************************

----목차----

1. 리눅스 특수권한 개념

2. setuid란

3. setuid 사용 예시

4. setgid란, 명령어 "wall"

5. setgid 사용 예시

6. 중간정리

7. StickyBit란 

8. StickyBit 사용 예시

9. 특수권한 기호로 파일에 설정하기, 특수권한 설정 때 있는 버그

10. 총 정리

입니다.
-------------

여기서 못 찾은 정보는
운영체제 페이지 : https://mamu2830.blogspot.com/p/blog-page_14.html
리눅스 독학 페이지 : https://mamu2830.blogspot.com/p/blog-page_13.html
에서 찾아보세요!

---

1. 리눅스 특수권한 개념

리눅스엔 특수권한이라고 불리는 "SetUID, SetGID, StickyBit"가 있는데요 이 3가지   (SetUID{s}, SetGID{s}, StickyBit{t}) 모두 "실행권한(x,excute)"에 관련된 개념입니다.
그래서 3가지 모두 파일의 실행에 관련된 기능으로 사용되고, 기호도 "실행"자리에 생깁니다. 

무슨 소리냐, 권한이 "u(소유자), g(그룹), o(other)"순으로 있는 것 처럼
"SetUID"를 파일에 설정하면 "소유자(u)의 실행권한"에 x대신 "s"가 들어가고
"SetGID"를 파일에 설정하면 "그룹(g)의 실행권한"에 x대신 "s"가 들어가고
"StickyBit"를 파일에 설정하면 "other(o)의 실행권한"에 x 대신 "t"가 들어갑니다.






위 사진은 기존 "777(rwxrwxrwx)"이던 파일에 특수권한(SetUID + SetGID + StickyBit =7000)를 모두 준 모습(7777)으로,
이렇게 실행자리에 "x" 대신 s(SetUID), s(SetGID), t(StikcyBit)가 들어간 모습을 볼 수 있습니다.

'네? SetUID + SetGID + StickyBit = 7000이라니 무슨소린가요???'

무슨소리냐면 그림을 보여드리며 설명해드릴게요~




위 그림처럼

기존에 권한이 "r, w, x"순으로 "4, 2, 1"이여서 총 8진수 1자리를 가진 것 처럼 "특수권한"
"s(SetUID), s(SetGID), t(StickyBit)"도 각각 "4, 2, 1"을 가지며 기존 rwx와 같은 방식으로, 수가 맨 오른쪽에서부터 왼쪽으로 2배씩 증가하는 규칙입니다.

위의 "특수권한"이 왜 맨 외쪽에 있느냐? 그림이 무슨 의미이냐? 하실텐데요.
사실 권한은 [][][] 이렇게 3자리만 있는게 아니라
"특수권한, UID, GID, Other"순으로 "[][][][]" 4자리가 있던 겁니다.

지금까지 저희가 "chmod 777 [파일]"처럼 바꾼 것도 맨 앞의 "특수권한을 생략한 것"이였다는 거죠. 사실은 "chmod 0777 [파일]"라 표현하는게 정확한 표현입니다.

특수권한을 주는 방법은 기존의 권한 법과 똑같이 기호로 주는 법과 번호로 주는 법 둘다 있습니다. 기호로 주는 건 매우 간단하므로 나중에 알려드리겠습니다.

우선 번호로 특수권한을 주는 방법은
chmod [권한 번호] [파일] 이렇게 하는겁니다.

예를 들어, 기존에 권한이 "755"이던 파일에 "SetUID"를 주고싶다? "chmod 4755" [파일]
이고

기존에 "755"이던 파일에 SetGID를 주고싶다? "chmod 2755 [파일]" 이렇게 하시면 됩니다.

StickyBit만 주고싶으면 "chmod 1755 [파일]" 이겠죠?

그럼 SetUID, SetGID, StickyBit 모두 주고싶으면 어떻게 할까요? 네 모두 더한 "7000"을 붙여주면 됩니다 "chmod 7755 [파일]" 이렇게 말이죠.


여기서 "SetUID, SetGID, StickyBit"의 기호(s, s, t)순서와 누가 4000이고 2000, 1000이냐가 헷갈리실텐데요.

"SetUID, SetGID, StickyBit"순서를 쉽게 외우는 방법은, 기존 권한이           u(user), g(group), o(other)순일 걸 생각하시면 잘 외워질거에요 무슨 소리냐면







SetUID는 "UID"니까 "u(user)"의 "x"자리에 들어갈 것이고, "u"는 첫 번째니까 4000!
SetGID는 "GID"니까 "g(group)"의 "x"자리에 들어갈 것이고, "g"는 두 번째니까 2000!
Stickybit는 나머지인 o(other)의 "x"자리에 들어가겠군! 그리고 마지막이니까 1000!
 이렇게 말이죠!


여기까지 정리해보면,

특수권한 "SetUID, SetGID, StickyBit"를 부여하면 각각 u,g,o 실행권한 자리에 "x"대신 s, ,s ,t가 들어가는 것이고

저 헷갈리는 특수권한 숫자(SetUID{4000}, SetGID{2000}, StickyBit{1000})는 기존의 권한처럼, "chmod" 명령어로 파일에 특수권한을 줄 때 쓰는 거랍니다..


여기서 마지막 개념!  "s(SetUID), s(SetGID), t(StikcyBit)" 모두 기존 파일에 실행권한 "x"가 있었다면 소문자 "s, s, t"가 들어가고 , 실행권한 "x"가 기존에 없었다면 
대문자 "S, S, T"가 들어갑니다

예시를 한번 보여드릴게요




"touch"로 "aloha"라는 파일을 만듬 -->" ll -d"로 "aloha"파일의 권한이 "x"가 없는
-rw-r--r--(644)인 것을 확인




"chmod 7644(기존 aloha파일의 권한은 644였다) aloha"로 파일에게 특수권한을 모두 줌
--> "ll -d" 로 파일에 실행권한이 없었기에 대문자 "S, S, T"가 들어간 것을 확인


이렇게 원래 실행권한 "x"가 없는 곳에 특수권한을 주면 소문자가 아닌 S, S ,T가 들어간다는 것을 확인해 보았습니다.

그럼 이번엔 원래 파일에 실행(x)권한이 있으면 특수권한을 줄 때 소문자인 걸 확인해 볼게요.






"chmod 7755(기존 7644에 'x'인 '1'을 ugo에 각각 더한 7755) aloha" 로 실행권한을 준 뒤
---> "ll -d"로 확인하니 파일에 실행권한 'x'가 있어서 소문자 "s, s, t" 이죠?


여기까지 3가지 특수 권한(SetUID{4000}, SetGID{2000}, StickyBit{1000}) 모두 실행에 관련된 기능이며,
실행권한 자리 "x" 대신에 s, s, t가 들가구, 파일에 실행권한 'x'가 없었으면 대문자 S, S, T가 들어간다는 것을 배운겁니다!

---

2. setuid란

SetUID(s)란, 말 그대로 파일을 실행할 때 Set(적용해라) UID(파일의 소유자로)입니다.

다시말해, SetUID가 적용된 파일을 실행하면, 실행 파일이 끝날 때 까지
파일의 소유자의 UID가 되는 겁니다. 

그럼 왜 "소유자 자체"가 아니라 "소유자 UID"로 바뀌는 것일까요? "UID"란 계정을 가리키는 "유일한 숫자"여서 "UID를 쓴다"는 것은, "UID가 가리키는 계정을 사용하는 것"과 마찬가지이기 때문입니다.

이것이 얼마나 대단하고 위험 한 것이냐면 SetUID가 설정돼 있는 "root"의 파일을 실행하면
실행이 끝날 때 까지 실행하는 사람의 UID가 root의 UID "0"이 되어  root의 권한을 갖는 겁니다.

그래서 실제로 잘못 설정하면 큰일나기에 주의해서 사용해야 합니다.(실제로 사용할 일은 별로 없음), 놀라운 것은 이 메커니즘을 이용해 해킹하는 방법도 있었다고 하네요 ㄷㄷ

자 그럼 확실하게 배우기 위해 한번 "SetUID" 얼마나 사용되고 있는지 체감해볼까요?

"root"로 로그인한 상태에서
리눅스 터미널에 "find / -perm -4000" 을 쳐 봅시다.
"find(뭔가를 찾겠다) /(최상위 루트디렉토리 "/"에서) -perm(permission,권한이)
-4000(4000{SetUID}가 있는 것을)"

그러면





이렇게 생각보다 많은 파일이 나오며 실제로 SetUID가 잘 쓰이고 있는 것을
확인 할 수 있습니다~ 맨 위에 제가 아까 예시를 들기 위해 만든 "aloha"도 있네요 ㅋㅋㅋ

---

3. setuid 사용 예시

먼저 "SetUID"가 사용되는 예시를 보여드릴텐데요 이 "SetUID"라는 기능은 "유저와 그룹" 포스트에서 배운 "/etc/passwd" 라는 "유저에 대한 정보가 들어있는 파일"을 사용할 때 쓰입니다.

이 "/etc/passwd"는 유저들의 정보가 저장되는 데이터베이스 파일이기 때문에, 저희가 "passwd" 라는 명령어를 이용해 유저의 패스워드를 바꾸면 그 변경된 정보는 "/etc/passwd"에 적힙니다.
(물론 "/etc/passwd"에 적힌 패스워드는 바로 "/etc/shadow"로 이동됨)





그리고 사진을 보시면 "-rw-r--r-- 1 root root" 이렇게 "/etc/passwd"파일을 변경할 수 있는 "w"권한은 소유주인 "root"에게만 있습니다. 다른 사람은 변경할 수 가 없죠.

그런데도 저희들은 "root"이외의 유저로도 로그인한 상태로 아무렇지 않게 "passwd"라는 명령어로 패스워드를 바꿔왔었습니다. 뭔가 이상하죠?

그러면 지금까지 어떻게 일반유저들이 패스워드를 바꿀 수 있었고, 변경된 내용을 어떻게 "/etc/passwd"에 적용할 수 있었을까요?

이것이 바로 "SetUID"란 특수권한으로 인해 가능한 일이였습니다!

바로 "/usr/bin/passwd"라는 명령어 파일에 "SetUID"권한이 부여가 돼 있기 때문에 일반 유저가
"passwd"란 명령어를 실행했을 때 일반유저의 UID가 "/etc/passwd"파일의 소유주인 "root"로 적용돼서, root인 양 /etc/passwd 파일의 내용을 변경할 수 있었던 것입니다.

...

'에? 명령어 파일? 뭔소리야?' 하실 분들이 있을거란 걸 압니다.
"리눅스 파일과 디렉토리" 포스트에서 "리눅스는 모든 것을 파일로 취급한다"고 했었는데
못 보신 분들이 있을 수 있기 때문이죠. 다시말해서

우리가 터미널 명령어라고 부르며 사용해오던 이 리눅스 "명령어"(ls, mkdir, passwd 등등 모든 명령어)들은 모두 사실 "실행파일" 이란 겁니다. 그리고 그 실행파일의 "o(other)"에 "r(read)와 x(excute)" 권한이 있어서 모든 유저가 사용할 수 있었던 거죠.

저희가 편하게 터미널에서 "ls"라고 치면 이것은 사실 "usr/bin/ls" 란 실행파일을 실행시킨 것이라는 겁니다.

같은 맥락으로 저희가 패스워드를 바꿀 때 사용하는 "passwd" 명령어도 사실은 "/usr/bin/passwd" 란 실행파일을 실행시킨 겁니다.

이런 명령어 실행파일들은 대부분 bin(binary)이나 sbin(system binary) 디렉토리에 들어있습니다.

계속해서 SetUID가 적용된 "/usr/bin/passwd"란 실행파일에 "ll -d"를 해보시면




이렇게 나옵니다. 뭔가 보이시나요? 아뇨 그 빨간색 이름 말고요,  권한 부분을 좀 더 주의깊게 보십쇼.





보이시나요? "소유주의 권한자리 u(user)"의 실행권한 "x"가 있을 곳에 저 소문자
"s"라는 것이?  이걸 보고 우리는 이제 실행권한 "x"가 있는 파일에 "SetUID"도 설정됐다는 것을 알 수 있습니다

이처럼 "SetUID"는 다른 사람의 파일을 실행할 때 소유자 권한이 필요한 경우 사용합니다.

---

4. setgid란, 명령어 "wall"

SetGID(s)란, 파일을 실행할 때 Set(적용해라) GID(파일의 그룹으로)입니다.

SetUID에 대해 먼저 배웠기 때문에 "SetGID"는 무슨 기능인지 대충 예상이 되실 겁니다.
"SetGID"가 설정된 파일을 실행하면, 실행이 끝날 때까지 자신의 GID가 파일 그룹의 GID로  바뀌는 거죠.

하지만 "SetUID"과 비교해보면 "SetGID"가 필요한 명령어파일은 그리 많진 않아요


한번 봐볼까요? UID처럼
root로 로그인하여

"find / -perm -2000" 해보는거죠. (SetGID가 2000이니까)





해보시면 그래도 생각보단 꽤 나옵니다.
하지만 저 명령어중에서 저희가 실제로 사용하는 명령어는 그리 많진 않아요

저희는 저기 중에서 /root/aloha다음에 있는  "/usr/bin/wall" ,즉 "wall"이라는 명령어를 사용해 "SetGID"를 테스트 해볼게요~

일단 "wall"이란 명령어가 뭔지를 알아야겠죠?

"wall" 명령어는 "write to all"의 줄임말로 우리가 아는 "벽"이 아닙니다.
"write to all"이란 뜻대로 모든 유저(모든 터미널)에게 메세지를 보내는 명령어죠
네트워크를 조금 아시는 분들이라면 그냥 브로드캐스트라고 생각하시면 됩니다.

사용법은 매우 간단합니다.

wall(write to all) [옵션] [보낼 메세지] 또는 wall [옵션] --> 내용적고 "ctrl + D"
입니다.

옵션으론

 -"n" : 누가 보냈는지 적지 않음(root만 사용가능)
이 있습니다. "-n"이 원래 무슨 영어인지 아무리 찾아봐도 안나와서 못 썼습니다 ㅠ

그런데 "-n" 옵션이 누가 보냈는지를 가리는건데 "root"만 사용이 가능하니 결국
누가 보냈는지 안 보이면 "root"가 보낸 걸 알 수 있다는 함정..

"-n"옵션만 빼면 이 "wall"이란 명령어는 root뿐만 아니라 모든 유저가 사용이 가능합니다

테스트를 위해 리눅스에서 터미널을 3개를 열어서 각각 "root"를 포함한
3명의 유저로 로그인 해보겠습니다.

저 같은 경우 "root", "mamu", "korea"로 로그인 했습니다.

새로운 터미널을 여는 건 터미널에서 우클릭을 하신다음 "새 창" 또는 "새 탭"을 누르시면
됩니다. 개인적으론 "새 탭이 좀더 편합니다"

새 탭을 2개 더 여신다음 각각 다른 유저로 "su - [유저이름]" 로그인 하시면 됩니다~

그러면

이렇게 3개의 터미널에 각가 다른 유저가 로그인 된 모습이 될 겁니다~

그럼 이제 "root"에서 "wall"를 사용해볼게요

이렇게  root에서 "wall hello everybody?" 하니 --->
root로 부터 브로드캐스트 메세지가 보내졌다고 뜹니다.
그리고 다른 일반 유저들을 눌러 확인해보면

이렇게 일반유저 "mamu"에서 봐도 root에게 메세지가 왔다는 것을 볼 수 있습니다.

이번엔 일반 유저가 "wall"를 사용해볼게요

이렇게 "mamu"에서 "wall Hi admin!"이라고 보냈습니다 --->

"root"로 가서 확인해 보면

"mamu"로 부터 브로드캐스트 메세지가 왔다고 뜨면서 잘 사용되는 걸 볼 수 있죠?

-->

다른 일반유저 "korea"로 가서 확인해 보아도

이렇게 "root", "mamu"에서부터 메세지를 잘 받은 모습입니다.

그리고 "root"로 돌아와서 옵션 "-n"을 써서 "wall -n Who am I?"라 보내고 -->

다른 유저 "mamu"로 와서 보면

이렇게 누가 보냈는지는 안뜨고 간략하게 메세지가 옵니다.

그리고 이번에 일반유저 "mamu"로도 "-n"옵션을 사용해보려 하지만

이렇게 권한이 없다며 사용이 안됩니다.

여기까지  "wall(write to all)" 명령어에 대해 알아보겠습니다.

그럼 왜 "SetGID"를 설명하는데 뜬금없이 "wall"이란 명령어를 설명했는지는

바로 밑에서 알려드릴게요~

---

5. setgid 사용 예시

자 그럼 왜 SetGID가 사용되는 예시에 "wall"을 설명을 했느냐,
위에서 배운대로 "wall"이란 명령어는 "모든 유저(터미널)"에 메세지를 보내는
명령어로 누구나 사용이 가능했죠?
이 누구나 사용이 가능하다는 것에서 이미 "Feel"이 오셨을 겁니다.

그렇습니다 이 누구나 "wall" 명령어를 사용가능했던 이유는 바로 "wall"의 원래 실행파일
/usr/bin/wall 에 SetGID가 설정돼 있기 때문이였습니다~

자 "ll -d /usr/bin/wall" 이렇게 파일의 권한을 확인해 봅시다.

뭐가 보이시나요? 노란색 이름 말구요~ 권한부분과 그룹부분을 보세요.

일단 g(group) 부분의 실행권한에 소문자 "s"가 보이는 걸로 봐선
그룹에 실행권한이 있는 파일에 "SetGID"까지 설정된 걸 알 수 있죠.

그리고 또 하나 주목해야할 점, 오른쪽에 소유그룹 이름을 보시면 "tty"라고 보이실겁니다.

어라? 난 저런 그룹을 만든 적이 없는데? 하실텐데
저건 원래 리눅스 시스템에서 사용되는 그룹입니다.

원래 1000미만의 GID를 가진 그룹은 시스템에서 쓰이는 그룹이라고 생각하시면 됩니다.

한번 확인해 볼까요?
"more /etc/group" 이렇게 말이죠(more은 걍 제가 사용하는 것으로 ,"cat, vi 등" 파일 내용을 읽는 명령어는 아무거나 사용 가능)

우왉.. 길다 다 필요 없고 제가 밑줄을 친 "tty"란 그룹만 보면 됩니다.
보시면 "GID가 5인 tty란 그룹이 있죠"?

자 그럼 이  "tty"가 무엇을 의미하며,  "tty"란 그룹이 어디에 사용되는 것이냐?

"tty" 는 "TeleTYpewriter"의 줄임말이며 이것은 통신에 사용되던 전기식 타자기인데
유닉스계열(리눅스) 운영체제에선 이걸 "터미널"을 가리키는 용어로 사용합니다.

말이 좀 어려운데 그냥 "tty = 터미널" 입니다.

"디렉터리와 파일" 포스트에서 "리눅스는 모든 것을 파일로 다룬다는 것"을 썼었는데, 기억하시나요? 기억 안나시면 다시 보고오세요 ㅎ
마찬가지로 이 "tty", 즉 "터미널"도 파일로 존재합니다

바로 장치들을 모아둔 /dev/ 디렉터리에 /dev/tty로 말이죠!
"ll -d /dev/tty"를 쳐봅시다.

자 이렇게 /dev/tty란 파일을 확인해 보시면
파일은 "c" 즉 "character special" 파일인 것을 알 수 있고
소유자는 "root", 그룹은 "tty"인 것을 알 수 있습니다.

자 그룹이 "tty"로 돼 있다는 것은 그룹 "tty"에 속한 사람만 사용할 수 있다는 뜻이겠죠?
이렇게 "tty"란 그룹은 "/dev/tty(터미널)"을 사용하기 위한 그룹이였다는 것을 알았습니다.

아이고 그래서 우리가 배운 "wall" 명령어랑 무슨 관계가 있냐고요? 원래도
"/dev/tty"의 o(other)에 "rw"가 있어서, 모든 유저가 각자의 터미널을 읽고 쓸 순 있지만

"wall"은 "모든 터미널에 메세지를 보내는 명령어"이기 때문에 그 이상의 많은 권한이 필요합니다. 그리고 터미널은 사용하려면 "tty"그룹이여야 하죠

그래서 "/usr/bin/wall"에 SetGID를 걸어 "wall" 명령어 즉, "/usr/bin/wall" 파일을 실행할 때 GID가 "tty"의 GID(5)가 되어서 "/dev/tty"를 사용할 수 있게 한겁니다.

여기까지만 끝나면 SetGID의 기능이 끝나면 좋을텐데...

아쉽게도 "SetGID"엔 한 가지 다른 기능이 또 있습니다.

그것은 바로 디렉터리에 "SetGID"를 설정했을 경우 그 디렉터리 안에 파일을 만들면
그 누가 만들더라도 디렉터리의 GID로 적용되어 생성됩니다.

다시말해서 "root"가 공용디렉터리를 만들고 거기에 SetGID를 설정할 경우
어떤 유저든 공용디렉터리 안에 파일을 만들면 그 파일의 그룹은 "root"가 된다는 겁니다.

사실 이런 상황이 생기게 된 이유는 "리눅스 권한" 부분에서 배운
"디렉터리에 권한이 부여되면 그 밑 파일까지 적용되는 현상"이 특수권한에도
적용되어 나타난 현상인데요.

"디렉터리" 자체가 기능을 가진 파일이고, 사용하기 위해선 실행 권한이 필요하다 했었죠?
그리고 "SetGID"는 실행을 할 때 파일의 그룹의 GID로 적용되는 특수권한이고요

그래서 그 디렉터리 내부에 파일을 만들면 디렉터리 기능이 "실행"되는 것이기 때문에
내부 파일들에도 모두 "SetGID"가 적용하게 되는 겁니다.

그래서 이런 것을 사용해서 디렉터리에 SetGID를 설정하면 그 안에 누가 파일을 만들든
디렉터리 그룹으로 만들어진다 라는 것입니다.

그러면 여기서 의문이 드실겁니다.
'아니 SetGID가 디렉터리에 설정됐을 때 그 밑 파일까지 영향을 미친다면 SetUID로 마찬가지아냐? 그런데 왜 SetUID는 소유자를 못바꾸지?'
라고 말이죠

그런데 원래 유닉스계열 운영체제(리눅스)에선 파일의 소유자를 바꾸는 것은
관리자 "root"만 가능하게 설정이 돼 있기 때문에 다행이도 "SetUID"에선
"SetGID"와 같이 디렉터리 하위에 모두 적용되는 상황은 생기지 않는 것입니다.

다시말해서 "root"가 한 디렉터리에 SetUID를 설정했고 다른 유저가 그 디렉터리
내부에 파일을 만들었을 때, 디렉터리의 "SetUID"의 기능을 실행하는 건 "root"가 아니라 "일반유저"이기 때문에 소유자가 변경이 안되는 거죠.

그래서 이런 기능은 "SetGID"에만 있다고 외우는 것입니다.
그럼 "SetGID"가 디렉터리 안 파일에게 영향을 미치는 것을
사진을 통해 보여드릴게요, 그 과정은

1. "/"에 모두가 접근 가능하고 SetGID을 적용시킨 "everybody"란 디렉터리를 만듬

2. 일반 유저 "mamu"로 "/everybody"디렉터리에 들어가 그냥 파일과 디렉터리를 만들어
SetGID가 적용되나 확인

3. "mamu"로 만든 디렉터리 안에 또 파일을 만들어 SetGID를 사용할 디렉터리 바로 밑까지만 적용되는지 아니면 모두 적용되는 지 확인

"mkdir everybody"로 "everybody"란 디렉터리를 만듦 -->

"chmod 2777 everybody"로 everybody디렉터리에 rwxrwsrwx권한(2777)을 부여-->

"ll -d everybody"로 확인

위 사진에서 짤렸지만 "cd everybody/"로 디렉터리 내부로 이동한다음-->
"su mamu"로 "mamu"로 로그인 -->
"touch testForFile.mamu"로 파일 생성 -->
"mkdir TestForDirectory.mamu"로 디렉터리 생성-->
"ll"로 만든 모든 파일이 "SetGID"의 영향을 받아, 그룹이 "root"로 바뀐 것을 확인 -->
그리고 디렉터리는 심지어 "SetGID"가 또 설정된 것을 확인

"cd testForDirectory.mamu/"로 "mamu"가 만든 디렉터리 내부로 또 이동한 뒤-->
"mkdir 123 , touch 3535"로 디렉터리와 파일을 생성-->
"ll(ls -l)"로 SetGID가 디렉터리 바로 밑 파일까지가 아닌, 하위 모든 파일에 적용되는 것을 확인

---

6. 중간정리


아이고.. 오늘도 참 길고 어렵네요... 그래서 중간 정리를 또 하고 가야할 것 같습니다.

1. 특수권한 "SetUID, SetGID, StickyBit"를 부여하면 각각 u,g,o 실행권한 자리인 
"x" 대신 "s, ,s ,t"가 들어간다

2. 특수권한 숫자(SetUID{4000}, SetGID{2000}, StickyBit{1000})는 
"chmod [권한숫자] [파일]"처럼, 파일에 특수권한을 줄 때 쓰는 것이다.

3. "SetUID"란 Set(적용해라) UID(파일 소유자 UID로)서, 파일을 실행할 때 
"소유자가 되어야하는 경우" 사용하는 특수권한이다.

4. 명령어 "wall"이란 모든 터미널에 메세지를 보내는 명령어다 

5. "SetGID"란 Set(적용해라) GID(파일의 그룹 GID로)서, 파일을 실행할 때 
"그룹이 되어야하는 경우" 사용하는 특수권한이다. 

6. "SetGID"를 디렉터리에 설정하면, 디렉터리 안 모든 파일에 적용되어 누구든 그 안에 파일을 만들면 그 파일 그룹이 디렉터리의 그룹이 된다.

7. 리눅스에선 소유자를 바꾸는 건 "root"만 가능하게 설정되어 있기 때문에 디렉터리에
"SetUID"를 설정해도 그 디렉터리 안에 만드는 파일들의 소유자가 바뀌는 일이 없다.

---

7. StickyBit란

뭔가 SetUID, SetGID는 둘다 "Set"으로 시작하고 "UID, GID"를 쓰니까 쉽게 이해가
되는데 왜 뜬금 없이 "StickyBit"란 연관없는 용어가 나왔는지 의아하실겁니다.

왜 "StickyBit"는 혼자 이름이 이렇게 독특하냐면 이건 원래 리눅스 특수권한용으로
나온 용어가 아니기 때문입니다.

"StickyBit"는 원래 유닉스 운영체제에서 실행파일의 실행속도 향상을 위해 사용되던
개념입니다.

이 StickyBit개념을 자세하게 말하자니 "운영체제 개념"이 좀 많이 필요해 어려우니 매우 간단하게 설명을 할게요.

원래 우리가 프로그램(실행파일)을 실행하면 프로세스가 되어 메모리에 올라가죠?
그리고 프로세스 사용이 끝나면 다시 메모리에서 내려오고요.

그런데 자주 사용하는 실행파일도 사용이 끝나면 메모리에서 내려오니까, 실행할 때마다 다시 메모리에 올라가는 시간을 줄이고자 "StickyBit"란 기능을 도입했는데

이걸 파일에 적용하면 "Sticky"뜻처럼 실행이 끝나도 메모리에 딱 "붙어있어"서 내려오지않아, 매번 실행할 때 마다 메모리에 올라가는 시간이 단축되는겁니다.

하지만 시간이 지나 컴퓨터 기술이 매우 좋아지고 하드웨어 기능도 좋아져서 이젠
"StickBit"란 기능이 있으나마나 해집니다. 그래서 이젠 사용을 안하게 됐습니다.

여기까지가 과거의 "StickyBit"였고요

그럼 현재의 특수권한의 "StickyBit"란 뭐냐? 과거의 "StickyBit"기능은 아예 없고
다른 기능을 합니다.

그것은 바로 "다른 사람의 파일을 변경할 수 없다" 입니다.

이것을 이해하려면 전부터 이야기 했던 "리눅스 권한"에서의 "디렉터리의 권한이
바로 밑 파일까지 적용된다"를 이해해야 합니다.

원래 디렉터리의 o(other)에 "rwx"와 같이 권한이 있으면, 디렉터리 내 파일의 o(other)에 "rwx"권한이 없어도 다른 유저가 그 파일을 강제로 변경할 수 있었죠?

"StickyBit"는 그런 걸 일을 막는, 진정한 "공유 디렉터리"를 만들기 위해 사용하는 개념입니다.

여기서 이런 의문이 나올 수 있습니다. '아니 그러면 디렉터리 o(other)에 "wx"권한을 안주면 되는거 아님? 굳이 StickyBit를 왜 씀?' 이라고요

아니죠... 디렉터리에 o(ohter)에 "wx"권한이 없으면 소유자와 그룹에 속한사람들 말곤 디렉터리 사용을 아예 못하잖아요. 아직 개념이 부족하시군요? 다시 "리눅스 권한" 포스트를 보고오십쇼! https://mamu2830.blogspot.com/2019/09/rwx.html

그렇기에 그 누구라도 디렉터리를 사용할 수 있게, 하지만 디렉터리 내 다른 사람의 파일은
건들지 못하게 하기 위해 "StickyBit"개념을 사용하는 겁니다.

외우는 방법은 "StickyBit"를 디렉터리에 적용하면 "Sticky"란 뜻처럼, 파일이 디렉터리에 딱 붙어있어 소유자 말곤 변경할 수 없게한다! 라고 전 외웠어요...

물론 관리자는 제거할 수 있죠. 여기서 말하는 관리자란 "StickyBit가 설정된 디렉터리의
소유자" 입니다. 심지어 자기가 "StickyBit"가 설정된 디렉터리 관리자라면
그 디렉터리 안에 "root"가 만든 파일도 변경이 가능합니다.(삭제, 수정 등)

물론 일반 파일도 StickyBit를 설정할 순 있습니다만, 디렉터리가 아니기 때문에
별 의미가 없어요~

---

8. StickyBit 사용 예시

이 "StickyBit"는 모두 사용하는 공용디렉터리엔 대부분 설정 돼 있다고 보면 되는데요
가장 대표적인 예시엔 "/tmp(temporary files)"가 있습니다.

"/tmp/"가 뭔지 잘 모르시면 "상위 디렉터리 정리" 포스트를 보고 오셔야 되겠지만
저는 친절하니까 다시 설명을 해드릴게요~

임시파일이란 실시간으로 실행되는 프로세스가 자주 사용하는 정보가 있다면 그걸 파일 형태로 만들어 둔 다음 쓰는겁니다, 그러면 한번 만들면 갖다 쓰기만 하면 되니 매우 빨라지겠죠?

하지만 그게 영구적인 파일이라면 점점 용량을 차지할테니, 리눅스 시스템에 종료될 때 자동으로 삭제가 되는 임시파일로 만드는 겁니다.  그리고 그런 임시파일들은 이름 뜻 그대로
"/tmp(temporary files)/"디렉터리에 저장되는 겁니다.

이렇게 중요하다면 중요한 /tmp/ 디렉터리는 모든 유저가 사용하지만, 다른 유저의
임시파일을 갑자기 삭제한다거나 변경하면 다른유저는 버그가 발생할 수 있겠죠?
그렇기에 "StickyBit"로 설정해둔겁니다.

---

9. 특수권한 기호로 파일에 설정하기, 특수권한 설정 때 있는 버그


지금까지 SetUID, SetGID, StickyBit에 대해서 특수권한 번호로 파일에 권한을
부여하는 방법만 알려드렸는데

이제 기호로 권한을 부여하는 방법을 알려드리겠습니다.
기호로 권한 바꾸는 것도 매~~우 쉽습니다.
저희가 지금까지 SetUID(s), SetGID(s), StickyBit(t)를 기호를 외웠잖아요?

SetUID(s)는 제가 말했던 것처럼 "u(user)"의 실행권한 자리에 들어가니까
추가하거나 제거하고 싶으면
chmod u["+" or "-" or "="]s [파일] 입니다.

무슨소리냐

SetUID를 추가하고 싶으면 "chmod u+s [파일]"
제거하고 싶으면 "chmod u-s [파일]" 이렇게 하는거죠
기존권한과 똑같이 "* /" 이런 건 없습니다.


그럼 SetGID(s)는 어떻게 할까요? "g(group)"의 실행권한 자리에 들어가니까
chmod g["+" or "-" or "="]s [파일] 입니다.

SetGID를 추가하고 싶으면 ""chmod g+s [파일]" 이렇게 말이죠



StickyBit는 마지막이니 느낌이 오실겁니다 "o(other)"의 실행권한 자리에 들어가니까
chmod o["+" or "-" or "="]t [파일] 입니다.

아 참고로 "="는 말 그대로 우항의 그대로 바꾼다는 거에요
그래서 원래 파일의 권한이 rwxrwxrwx(777)라고 해도
"chmod u=s [파일]" 이렇게 해버리면 "--Srwxrwx(4077)" 이렇게 됩니다.



아 특수권한 설정 때 있는 버그가 뭐냐고요?

원래 "chmod" 이용해 파일 권한을 바꿀 때 "권한숫자"와 "권한기호"로 바꾸는 방법
총 2가지가 있다고 했죠?

그런데 "기존에 특수권한이 있는 파일"을 "권한 숫자 방법"으로 바꿨을 때
안 바뀌는 버그가 있습니다. 이럴 땐 당황하지 마시고 "권한기호"로 바꾸시면
바뀝니다.

---

10. 총 정리


아 사실은 정말 간단하게 포스트할려면 정말 빨리 끝낼 수 있지만 더 자세히, 더 간단히 설명하려고 나름 노력하다보니 정~말 긴 포스트가 됐네요 ㅠㅠ 긴 글 읽느라 정말 고생하셨습니다. 마지막으로 총 정리를 하고 '특수권한'편을 마치도록 하겠습니다


1. 특수권한 "SetUID, SetGID, StickyBit"를 부여하면 각각 u,g,o 실행권한 자리인 
"x" 대신 "s, ,s ,t"가 들어간다

2. 특수권한 숫자(SetUID{4000}, SetGID{2000}, StickyBit{1000})는 
"chmod [권한숫자] [파일]"처럼, 파일에 특수권한을 줄 때 쓰는 것이다.

3. "SetUID"란 Set(적용해라) UID(파일 소유자 UID로)서, 파일을 실행할 때 
"소유자가 되어야하는 경우" 사용하는 특수권한이다.

4. 명령어 "wall"이란 모든 터미널에 메세지를 보내는 명령어다 

5. "SetGID"란 Set(적용해라) GID(파일의 그룹 GID로)서, 파일을 실행할 때 
"그룹이 되어야하는 경우" 사용하는 특수권한이다. 

6. "SetGID"를 디렉터리에 설정하면, 디렉터리 안 모든 파일에 적용되어 누구든 그 안에 파일을 만들면 그 파일 그룹이 디렉터리의 그룹이 된다.

7. 리눅스에선 소유자를 바꾸는 건 "root"만 가능하게 설정되어 있기 때문에 디렉터리에
"SetUID"를 설정해도 그 디렉터리 안에 만드는 파일들의 소유자가 바뀌는 일이 없다.

8. "StickyBit"는 다른 사람의 파일을 변경하지 못하게 하는 기능이고, 디렉터리에만 효과가 있다.

9. 특수 권한을 기호로 주는 방법은 "chmod [u, g, o]["+" or "-" or "="][s, s, t] [파일]"이다

10. 기존에 특수 권한이 있는 파일을 "숫자 방법"으로 변경시 변경이 안되는 버그가 있다,
이럴 땐 "기호를 사용해" 변경하면 된다.

---

흐아.. 이번엔 하루에 5시간씩 3일동안 투자해서 완료했네요 정말 힘들군요 허헣
틀린 정보나 오타 지적해주시면 바로 수정하겠습니다!

구글블로그 좋아요, 팔로우, 네이버 블로그 공감 눌러주신 분들
정말 감사합니다 ㅠㅠ 정말 큰 힘을 얻어서 힘내서 오늘도 포스트를 하고 있어요!

다음에 더 좋은 퀄리티 포스트로 뵙겠습니다~!