리눅스 네임스페이스

Linux namespaces
네임스페이스
원본 작성자알비로
개발자에릭 W. 비더만, 파벨 에멜랴노프, 알 비로, 키릴 고르쿠노프 외
초기 릴리즈2002년; 20년 전(2002년)
기록 위치C
운영 체제리눅스
유형시스템 소프트웨어
면허증GPLLGPL

네임스페이스는 커널 리소스를 분할하여 하나의 프로세스 세트가 하나의 리소스 세트를 보는 반면 다른 프로세스 세트가 다른 리소스 세트를 보는 리눅스 커널의 기능이다.이 기능은 리소스 및 프로세스 집합에 대해 동일한 네임스페이스를 갖는 방식으로 작동하지만, 이러한 네임스페이스는 서로 다른 리소스를 가리킨다.자원은 여러 공간에 존재할 수 있다.이러한 리소스의 예로는 프로세스 ID, 호스트 이름, 사용자 ID, 파일 이름 및 네트워크 액세스 및 프로세스통신과 관련된 일부 이름이 있다.

네임스페이스는 리눅스 용기의 기본적인 측면이다.

"namespace"라는 용어는 네임스페이스의 유형(예: 프로세스 ID)뿐만 아니라 이름의 특정 공간에도 종종 사용된다.

리눅스 시스템은 모든 프로세스에서 사용되는 각 유형의 단일 네임스페이스로 시작한다.프로세스는 추가 네임스페이스를 만들고 다른 네임스페이스를 결합할 수 있다.

역사

리눅스 네임스페이스는 Bell Labs의 Plan 9 전체에서 많이 사용되는 네임스페이스 기능에 의해 영감을 받았다.[1]

리눅스 네임스페이스는 2002년 마운트 네임스페이스 종류에 대한 작업을 통해 2.4.19 커널에서 시작되었다.2006년부터[2] 시작하여 미래에도 네임스페이스가 추가되었다.

사용자 네임스페이스의 도입으로 커널 버전 3.8에서 적절한 컨테이너 지원 기능이 완료되었다.[3]

네임스페이스 종류

커널 버전 5.6 이후 네임스페이스는 8종류다.네임스페이스 기능은 모든 종류에 걸쳐 동일하다. 각 프로세스는 네임스페이스와 연관되어 있으며 해당 네임스페이스와 하위 네임스페이스만 보거나 사용할 수 있다.이러한 방식으로 각 프로세스(또는 프로세스 그룹의 프로세스 그룹)는 리소스에 대한 고유한 보기를 가질 수 있다.격리된 리소스는 지정된 프로세스 그룹에 대해 생성된 네임스페이스 유형에 따라 달라진다.

마운트(mnt)

마운트 네임스페이스 제어 마운트 지점현재 마운트 네임스페이스에서 마운트를 만들면 새 네임스페이스로 복사되지만 이후에 생성된 마운트 지점은 네임스페이스 간에 전파되지 않는다(공유 하위 트리를 사용하면 네임스페이스[4] 간에 마운트 지점을 전파할 수 있음).

이 유형의 새 네임스페이스를 만드는 데 사용되는 클론 플래그는 "NEW NameSpace"의 줄임말인 CLONE_NEWNS이다.이 용어는 마운트 네임스페이스가 첫 번째 종류의 네임스페이스였고 설계자가 다른 네임스페이스가 있을 것으로 예상하지 않았기 때문에 설명되지 않는다(어떤 종류의 네임스페이스를 만들 것인지 알 수 없기 때문이다).

프로세스 ID(pid)

PID 네임스페이스는 다른 네임스페이스에서 독립된 프로세스 ID(PID) 집합을 가진 프로세스를 제공한다.PID 네임스페이스는 중첩되며, 즉, 새로운 프로세스가 생성될 때 현재 네임스페이스에서 초기 PID 네임스페이스까지 각 네임스페이스에 대한 PID를 갖는다.따라서 초기 PID 네임스페이스는 다른 네임스페이스와 다른 PID를 사용하더라도 모든 프로세스를 볼 수 있다.

PID 네임스페이스에서 생성된 첫 번째 프로세스에는 프로세스 ID 번호 1이 할당되며, 일반 초기화 프로세스와 거의 동일한 특별 대우를 받게 되는데, 특히 네임스페이스 내의 고아 프로세스가 여기에 부착되어 있다는 것이 가장 두드러진다.이것은 또한 이 PID 1 프로세스가 종료되면 PID 네임스페이스의 모든 프로세스와 모든 하위 프로세스가 즉시 종료된다는 것을 의미한다.[5]

네트워크(그물)

네트워크 네임스페이스는 네트워크 스택을 가상화한다.네트워크 네임스페이스는 생성 시 루프백 인터페이스만 포함한다.

각 네트워크 인터페이스(물리적 또는 가상)는 정확히 하나의 네임스페이스에 존재하며 네임스페이스 간에 이동할 수 있다.

각 네임스페이스에는 전용 IP 주소 집합, 자체 라우팅 테이블, 소켓 목록, 연결 추적 테이블, 방화벽 및 기타 네트워크 관련 리소스가 있을 것이다.

네트워크 네임스페이스를 파괴하면 그 안에 있는 모든 가상 인터페이스가 파괴되고 그 안에 있는 모든 물리적 인터페이스가 초기 네트워크 네임스페이스로 다시 이동된다.

프로세스 간 통신(ipc)

IPC 네임스페이스는 프로세스를 SysV 스타일 프로세스 간 통신으로부터 분리한다.이를 통해 서로 다른 IPC 네임스페이스에 있는 프로세스가 예를 들어 SHM 기능 제품군을 사용하여 두 프로세스 간의 공유 메모리 범위를 설정할 수 없게 된다.대신에 각 프로세스는 공유 메모리 영역에 동일한 식별자를 사용할 수 있고 두 개의 구별되는 영역을 생성할 수 있을 것이다.

UTS

UTS(UNIX Time-Sharing) 네임스페이스를 사용하면 단일 시스템이 서로 다른 프로세스에 대해 서로 다른 호스트 및 도메인 이름을 가질 수 있다."프로세스가 새로운 UTS 네임스페이스를 생성할 때...새로운 UTS 네임스페이스의 호스트 이름과 도메인은 발신자의 UTS 네임스페이스에 있는 해당 값에서 복사된다."[6]

사용자 ID(사용자)

사용자 네임스페이스는 커널 3.8 이후 사용할 수 있는 여러 프로세스 집합에서 권한 격리 및 사용자 식별 분리를 모두 제공하는 기능이다.[7]행정적 지원을 통해 실제로 사용자 프로세스에 높은 권한을 부여하지 않고도 관리 권한을 가진 컨테이너를 구축할 수 있다.PID 네임스페이스와 마찬가지로 사용자 네임스페이스는 중첩되며 각각의 새로운 사용자 네임스페이스는 이를 만든 사용자 네임스페이스의 하위 사용자 네임스페이스로 간주된다.

사용자 네임스페이스는 컨테이너의 관점에서 시스템의 관점으로 사용자 ID를 변환하는 매핑 테이블을 포함한다.를 들어, 루트 사용자는 컨테이너에 사용자 ID 0을 가질 수 있지만 실제로 소유권 검사를 위해 시스템에 의해 사용자 ID 1,400,000으로 처리된다.그룹 ID 매핑 및 소유권 확인에도 유사한 테이블이 사용된다.

관리 작업의 권한 분리를 용이하게 하기 위해 각 네임스페이스 유형은 생성 시점의 활성 사용자 네임스페이스에 기반한 사용자 네임스페이스에 의해 소유되는 것으로 간주된다.적절한 사용자 네임스페이스에서 관리 권한을 가진 사용자는 다른 네임스페이스 유형 내에서 관리 작업을 수행할 수 있다.예를 들어, 프로세스가 네트워크 인터페이스의 IP 주소를 변경할 수 있는 관리 권한을 가진 경우, 자체 사용자 네임스페이스가 네트워크 네임스페이스를 소유하는 사용자 네임스페이스와 동일하거나 상위 사용자 네임스페이스가 되는 한 그렇게 할 수 있다.따라서 초기 사용자 네임스페이스는 시스템의 모든 네임스페이스 유형에 대한 관리 제어권을 갖는다.[8]

제어 그룹(cgroup) 네임스페이스

cgroup 네임스페이스 유형은 프로세스가 구성원인 제어 그룹의 ID를 숨긴다.이러한 네임스페이스에서 프로세스가 어떤 제어 그룹의 일부인지 확인하는 프로세스는 실제 제어 그룹 위치와 ID를 숨기고 생성 시 설정된 제어 그룹에 실제로 상대적인 경로를 볼 수 있다.이 네임스페이스 유형은 Linux 4.6에서 2016년 3월부터 존재해왔다.[9][10]

시간 네임스페이스

시간 네임스페이스를 통해 프로세스는 UTS 네임스페이스와 유사한 방식으로 다양한 시스템 시간을 볼 수 있다.2018년 제안돼 2020년 3월 출시된 Linux 5.6에 상륙했다.[11]

제안된 네임스페이스

syslog 네임스페이스

이행내역

커널은 각 프로세스에 네임스페이스 종류당 심볼 링크를 할당함/proc/<pid>/ns/. 이 symlink가 가리키는 inode 번호는 이 네임스페이스의 각 프로세스에 대해 동일하다.이것은 각 네임스페이스를 심볼링크 중 하나가 가리키는 인코드 번호로 고유하게 식별한다.

읽기 링크를 통해 symlink를 읽으면 네임스페이스 종류 이름과 네임스페이스의 inode 번호가 포함된 문자열이 반환된다.

시스콜스

세 개의 syscall이 네임스페이스를 직접 조작할 수 있음:

  • 복제, 새 프로세스를 마이그레이션할 새 네임스페이스를 지정하는 플래그
  • 공유 해제, 프로세스(또는 스레드)가 현재 다른 프로세스(또는 스레드)와 공유 중인 실행 컨텍스트의 일부 연결을 해제할 수 있음
  • setns, 파일 설명자가 지정한 네임스페이스를 입력하십시오.

파괴

네임스페이스가 더 이상 참조되지 않으면 삭제되며, 포함된 리소스의 처리가 네임스페이스 종류에 따라 달라진다.네임스페이스는 세 가지 방법으로 참조할 수 있다.

  1. 네임스페이스에 속하는 프로세스에 의해
  2. 네임스페이스 파일에 대한 열린 파일첨자(파일 형식)에 의해/proc/<pid>/ns/<ns-kind>)
  3. 네임스페이스 파일의 바인딩 마운트(/proc/<pid>/ns/<ns-kind>)

입양

다양한 컨테이너 소프트웨어는 리눅스 네임스페이스를 cgroup과 결합하여 Docker[12] LXC를 포함한 그들의 프로세스를 분리한다.

구글 크롬과 같은 다른 애플리케이션은 네임스페이스를 사용하여 인터넷 공격으로부터 위험에 처한 자체 프로세스를 분리한다.[13]

또한 Util-linux에는 공유되지 않는 포장지가 있다.그 사용의 예는 다음과 같다.

CHELL=/bin/sh unshare --map-root-user --fork --pid chroot "${chrootdir}" "$@"

참조

  1. ^ "The Use of Name Spaces in Plan 9". 1992. Archived from the original on 2014-09-06. Retrieved 2016-03-24.
  2. ^ "Linux kernel source tree". kernel.org. 2016-10-02.
  3. ^ "Namespaces in operation, part 5: User namespaces [LWN.net]".
  4. ^ "Documentation/filesystems/sharedsubtree.txt". 2016-02-25. Retrieved 2017-03-06.
  5. ^ "Namespaces in operation, part 3: PID namespaces". lwn.net. 2013-01-16.
  6. ^ "uts_namespaces(7) - Linux manual page". www.man7.org. Retrieved 2021-02-16.
  7. ^ "Namespaces in operation, part 5: User namespaces [LWN.net]".
  8. ^ "Namespaces in operation, part 5: User namespaces". lwn.net. 2013-02-27.
  9. ^ Heo, Tejun (2016-03-18). "[GIT PULL] cgroup namespace support for v4.6-rc1". lkml (Mailing list).
  10. ^ Torvalds, Linus (2016-03-26). "Linux 4.6-rc1". lkml (Mailing list).
  11. ^ "It's Finally Time: The Time Namespace Support Has Been Added To The Linux 5.6 Kernel - Phoronix". www.phoronix.com. Retrieved 2020-03-30.
  12. ^ "Docker security". docker.com. Retrieved 2016-03-24.
  13. ^ "Chromium Linux Sandboxing". Retrieved 2019-12-19.

외부 링크