기본 콘텐츠로 건너뛰기

[linux] 뻔하지 않은 파일 퍼미션(file permissions) 끄적임. 정말 속속들이 아니?

1. [특수w]내 명의의 디렉토리라면 제아무리 루트가 만든 파일에 rwxrwxrwx 퍼미션이라 할지라도 맘대로 지울 수 있다. 즉 내 폴더안의 파일은 뭐든 지울 수 있다.
2. [일반rx]하지만 읽기와 쓰기는 other의 권한을 따른다.
3.[일반rwx]단 남의 계정 폴더는 그 폴더의 퍼미션을 따른다.
4.[일반]만약 굳이 sudo로 내 소유로 파일을 넣어놓더라도 달라지는건 없고, 단지 그 폴더의 other퍼미션에 write권한이 있으면 파일을 만들고 삭제할 수 있다.

5.디렉토리의 r권한은 내부의 파일이름 정도만 볼 수있다. 하지만 ls 명령의 경우 소유자, 그룹, 파일크기 등의 정보를 보는 명령어므로 정상적인 실행은 불가능하고, 부분적으로 실행됨.

frank@localhost:/export/frankdir$ ls rootdir/
ls: cannot access rootdir/root: 허가 거부
ls: cannot access rootdir/fa: 허가 거부
fa  root #이처럼 속한 파일(폴더)만 딸랑 보여준다.

frank@localhost:/export/frankdir$ ls -al rootdir/ # al옵션이 모두 물음표 처리된다..
ls: cannot access rootdir/root: 허가 거부
ls: cannot access rootdir/..: 허가 거부
ls: cannot access rootdir/.: 허가 거부
ls: cannot access rootdir/fa: 허가 거부
합계 0
d????????? ? ? ? ?             ? .
d????????? ? ? ? ?             ? ..
-????????? ? ? ? ?             ? fa
-????????? ? ? ? ?             ? root

하지만 웃긴건, r에는 읽기 기능이 가능하므로 그 폴더 안으로 cd가 되는 x권한이 없더라도 어떤 파일이 있는지 목록 정도는 알 수 있다. 하지만 r이라고 해서 vi로 그 안의 파일을 읽는것이 가능하냐고 묻는다면, 전혀 아니다. 결론부터 말하자면, vi로 파일을 읽는 것은 디렉토리의 x권한이 필요한 사항이다. 왜냐하면 해당 폴더가 어떤 파일을 가지고 이 파일들이 하드의 어느 위치에 있는지에 대한 정보들(inode포함)에 접근할 수 있어야 하는데 이는 디렉토리의 실행(x)권한이기 때문이다.

그렇다면 해당 파일을 touch해 a/mtime을 변경하고자 한다면?
파일에 대한 만들기/지우기/변경과 직접적인 관련이 있는 w권한이면 충분한가? 바로 위에서 말했다시피, 무슨 파일의 내용을 읽거나 이를 수정하는 등의 작업을 하려면 디렉토리의 특수 정보에 접근하기 위한 x권한이 항상 필요하다. 정리하자면, touch로 있는파일을 수정하거나, 없는 파일을 만들기 위한 최소한의 권한은 -wx인 셈이다.

6. 디렉토리의 x권한은 cd가 가능하고, 주어진 파일에 대해 상세정보를 볼 수있는 권한이 있다. 하지만 other의 권한이 --x라면 r이 없으므로 속한 파일명들은 알 수가 없다. 따라서 아래와 같은 결과가 나온다. 즉, 파일명 자체에 대한 접근권한인 r이 없으므로 ls는 전혀 동작할 수 없다.
frank@localhost:/export/frankdir/rootdir$ ls
ls: cannot open directory .: 허가 거부

7. 따라서 디렉토리에서 온전한 ls가 가능하려면 적어도 r-x의 권한이 필요하다.

8. 여기에 디렉토리에 대한 w는 그 안에 파일을 만들고 지울 수 있는 권한이다. 그렇지만 실제 지우려면 최소 '-wx'권한이 필요하다. 단, 저 권한만으로는 무슨 파일이 존재하는지 알고 있어야만 콕찝어 지우는것만 가능하다. 왜냐면 ls 등으로 속한 파일명을 알 도리가 없기 때문.

9. 디렉토리의 권한은 cacading으로 축소될 뿐이다? 그렇지 않다. 예를 들어
rootdir(--x)
├── fa
├── root
└── rootdir2(rwx)
    └── ohno
라면, rootdir안에서 ls로 아무것도 노출되지 않는다. 실제로는 fa, root, rootdir2가 존재하는지조차 알 도리가 없다. 다만 나는 여기에서 rootdir2가 존재한다는걸 미리 알기 때문에 다음과 같은 상황이 가능해진다.

frank@localhost:/export/frankdir$ cd rootdir/
frank@localhost:/export/frankdir/rootdir$ ls #안에 뭐가 있는지 알 도리가 없다. 변태적인 상황이 연출된다.
ls: cannot open directory .: 허가 거부
frank@localhost:/export/frankdir/rootdir$ cd rootdir2 #이런게 존재한다는걸 알고 감으로 들어갈 뿐이다.

#상위 폴더에서는 (--x) 였으므로 해당 권한이 cacading되어 여기서도 ls가 안될거 같지만, 아니다. 잘만 된다. 이 폴더를 list하기 위해서 필요한 권한은 이 폴더의 권한에만 종속되는 문제다. 다만, rootdir2까지 들어오기 위해서 rootdir은 x권한만 있으면 충분했을 뿐이다.
frank@localhost:/export/frankdir/rootdir/rootdir2$ ls -al
합계 12
drwxr-xrwx 2 root root 4096  5월 30 23:45 .
drwxr-x--x 3 root root 4096  5월 30 23:30 ..
-rw-r--r-- 1 root root   16  5월 30 23:35 ohno
frank@localhost:/export/frankdir/rootdir/rootdir2$ cat ohno
/usr/bin/python

# 이 파일에 x권한은 없지만 bash로 명시적으로 실행은 물론 가능~
frank@localhost:/export/frankdir/rootdir/rootdir2$ bash ohno
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
frank@localhost:/export/frankdir/rootdir/rootdir2$ touch ohyes #잘됨.

10. 만약 rootdir이 ---라면(즉 권한이 rwx모두 없다면)
rootdir(---)
├── fa
├── root
└── rootdir2(rwx)
    └── ohno

frank@localhost:/export/frankdir$ ls rootdir/rootdir2
ls: cannot access rootdir/rootdir2: 허가 거부
frank@localhost:/export/frankdir$ cd rootdir/rootdir2
-su: cd: rootdir/rootdir2: 허가 거부
frank@localhost:/export/frankdir$ touch rootdir/rootdir2/test
touch: cannot touch `rootdir/rootdir2/test': 허가 거부

9번의 결과와 달리, rootdir2안에 내용을 볼수도, 거기로 들어갈 수도, 어떤 파일을 만들수도 없다. rootdir2가 분명 rwx이지만, rootdir자체가 x권한이 없으므로, 그 하위 폴더로 rootdir2의 inode등의 정보도 전혀 줄 수 없어 rootdir2에 대한 포인터를 얻는 것 자체가 불가능하므로 위와 같은 결과가 연출된다.

보다시피 위에는 rootdir3라는 폴더는 없다.

frank@localhost:/export/frankdir$ touch rootdir/rootdir3/test
touch: cannot touch `rootdir/rootdir3/test': 허가 거부
frank@localhost:/export/frankdir$ ls rootdir/rootdir3
ls: cannot access rootdir/rootdir3: 허가 거부
frank@localhost:/export/frankdir$ cd rootdir/rootdir3
-su: cd: rootdir/rootdir3: 허가 거부

즉, 있고 없고에 따라 허가 거부가 되는게 아니라, rootdir선에서 그 하위폴더의 특정정보에 대해서는 진실 혹은 거짓, 그 어떤것도 대답하지 않는다는 뜻이다. 즉, 뭘해도 허가거부로 뜬다.

10. 내 아이디를 특정 그룹에 속하도록 했는데도 이상한 현상이 발생!

bob@localhost:/export/frankdir$ tail -1 /etc/group
alice:x:1003:bob
bob@localhost:/export/frankdir$ id #alice 그룹에 속하도록 변경했는데도 id(현재 유효하게 적용되고 있는 그룹들이 노출됨)에는 없다?
uid=1001(bob) gid=1002(bob) groups=1002(bob)
bob@localhost:/export/frankdir$ groups bob # 하지만 groups <id>에는 노출이 되고 있다.(groups명령어는 실제 /etc/group 파일에 근거해 결과 노출
bob : bob alice

#이는 실제 리눅스 시스템의 특성인데, 속한 그룹이 바뀐내용은 현상태에 바로 반영되지 않는다. 궁극적으로는 해당 아디디를 로그아웃하고 재로그인 하거나, 재부팅을 하면 바로 반영되며, su(switch user)를 사용하면 같은 효과를 낼 수 있다.
bob@localhost:/export/frankdir$ su - bob
암호:
bob@localhost:~$ id
uid=1001(bob) gid=1002(bob) groups=1002(bob),1003(alice) #alice에 속하는 정보가 정확히 노출되고 있음.

댓글

이 블로그의 인기 게시물

[인코딩] MS949부터 유니코드까지

UHC = Unified Hangul Code = 통합형 한글 코드 = ks_c_5601-1987 이는 MS사가 기존 한글 2,350자밖에 지원하지 않던 KS X 1001이라는 한국 산업 표준 문자세트를 확장해 만든 것으로, 원래 문자세트의 기존 내용은 보존한 상태로 앞뒤에 부족한 부분을 채워넣었다. (따라서 KS X 1001에 대한 하위 호환성을 가짐) 그럼, cp949는 무엇일까? cp949는 본래 코드 페이지(code page)라는 뜻이라 문자세트라 생각하기 십상이지만, 실제로는 인코딩 방식이다. 즉, MS사가 만든 "확장 완성형 한글 ( 공식명칭 ks_c_5601-1987 ) "이라는 문자세트를 인코딩하는 MS사 만의 방식인 셈이다. cp949 인코딩은 표준 인코딩이 아니라, 인터넷 상의 문자 송수신에 사용되지는 않는다. 하지만, "확장 완성형 한글" 자체가 "완성형 한글"에 대한 하위 호환성을 고려해 고안됐듯, cp949는 euc-kr에 대해 (하위) 호환성을 가진다. 즉 cp949는 euc-kr을 포괄한다. 따라서, 윈도우즈에서 작성되어 cp949로 인코딩 되어있는 한글 문서들(txt, jsp 등등)은 사실, euc-kr 인코딩 방식으로 인터넷 전송이 가능하다. 아니, euc-kr로 전송해야만 한다.(UTF-8 인코딩도 있는데 이것은 엄밀히 말해서 한국어 인코딩은 아니고 전세계의 모든 문자들을 한꺼번에 인코딩하는 것이므로 euc-kr이 한국어 문자세트를 인코딩할 수 있는 유일한 방식임은 변하지 않는 사실이다.) 물론 이를 받아보는 사람도 euc-kr로 디코딩을 해야만 문자가 깨지지 않을 것이다. KS X 1001을 인코딩하는 표준 방식은 euc-kr이며 인터넷 상에서 사용 가능하며, 또한 인터넷상에서 문자를 송수신할때만 사용.(로컬하드에 저장하는데 사용하는 인코딩방식으로는 쓰이지 않는 듯하나, *nix계열의 운영체제에서는 LANG을 euc-kr로 설정 가능하기도 한걸

[hooking, 후킹, 훅킹] Hooking이란?

source: http://jinhokwon.blogspot.kr/2013/01/hooking.html Hooking 이란? [출처] http://blog.daum.net/guyya/2444691 훅킹(Hooking)이란 이미 작성되어 있는 코드의 특정 지점을 가로채서 동작 방식에 변화를 주는 일체의 기술 이다. 훅이란 낚시바늘같은 갈고리 모양을 가지는데 여기서는 코드의 중간 부분을 낚아채는 도구라는 뜻으로 사용된다. 대상 코드의 소스를 수정하지 않고 원하는 동작을 하도록 해야 하므로 기술적으로 어렵기도 하고 운영체제의 통상적인 실행 흐름을 조작해야 하므로 때로는 위험하기도 하다. 훅킹을 하는 방법에는 여러 가지가 있는데 과거 도스 시절에 흔히 사용하던 인터럽터 가로채기 기법이나 바로 앞에서 알아본 서브클래싱도 훅킹 기법의 하나라고 할 수 있다. 이외에도 미리 약속된 레지스트리 위치에 훅 DLL의 이름을 적어 주거나 BHO(Browser Helper Object)나 응용 프로그램 고유의 추가 DLL(Add in)을 등록하는 간단한 방법도 있고 PE 파일의 임포트 함수 테이블을 자신의 함수로 변경하기, CreateRemoteThread 함수로 다른 프로세스의 주소 공간에 DLL을 주입(Injection)하는 방법, 메모리의 표준 함수 주소를 덮어 쓰는 꽤 어려운 방법들도 있다. 이런 고급 훅킹 기술은 이 책의 범위를 벗어나므로 여기서는 소개만 하고 다루지는 않기로 한다. 이 절에서 알아볼 메시지 훅은 윈도우로 전달되는 메시지를 가로채는 기법으로 다양한 훅킹 방법중의 하나이다. 메시지 기반의 윈도우즈에서는 운영체제와 응용 프로그램, 또는 응용 프로그램 사이나 응용 프로그램 내부의 컨트롤끼리도 많은 메시지들을 주고 받는다. 훅(Hook)이란 메시지가 목표 윈도우로 전달되기 전에 메시지를 가로채는 특수한 프로시저이다. 오고 가는 메시지를 감시하기 위한 일종의 덫(Trap)인 셈인데 일단 응용 프로그램이 훅 프로시저를 설치하면 메시지가 윈도우로 보내지기