[+WEEK5] PART5

5주차

• s: 실행 파일에 적용되는 setuid/setgid 권한
• 이를 실행하는 사용자는 파일 소유자 또는 그룹의 유효한 권한을 상속받음
• t: 디렉터리에만 관련된 스티키 비트(sticky bit)
  • 해당 디렉토리/파일을 소유한 사용자가 아닌 비root 사용자가 파일을 삭제하지 못하게 방지
• chattr(change attribute)

755: 소유자는 모든 권한을 갖고, 그 외 모든 사람은 읽기와 쓰기 권한을 가짐
700: 소유자는 모든 권한을 가지고, 그 외 모든 사람은 아무 권한이 없음
664: 소유자와 그룹은 읽기/쓰기 권한이 있으며, 나머지 사용자는 읽기만 가능함
644: 소유자는 읽고 쓰기가 가능, 그 외 모든 사람은 읽기만 가능함
400: 소유자만 읽기 가능

• 664는 시스템에서 특별한 의미

• 내가 파일을 만들 때 할당하는 기본 권한으로, umask 명령으로 확인할 수 있으나 0002이다.(보통)

• setuid 권한은 실행 파일을 소유자 권한으로 실행하도록 시스템에 알릴 때 사용

  • 만약 파일이 root 소유인 경우라면, 문제가 발생할 수도 있다.

• chmod로 파일의 권한을 변경할 수도 있다. 원하는 권한 설정을 명시적으로 지정하거나(ex: 644) 단축어를 사용
  chmod +x /tmp/masktest

• chown을 사용하여 소유권을 변경할 수도 있다.

• 그룹의 경우 chgrp

프로세스 권한

• 런타임 권한과 관련된 다양한 사용자 id
  • RUID(Real User ID): 프로세스를 시작한 사용자의 UID
    • 프로세스 자체에서는 getuid(2)를 사용해 자신의 ruid를 얻을 수 있고
• 셸: stat -c "%u %g" proc/$pid/을 사용해 쿼리할 수도 있다.
  • EUID: 리눅스 커널은 메시지 대기열과 같은 공유 리소스에 접근할 때 EUID(유효 사용자)를 사용해 프로세스가 갖는 권한을 결정한다.
    • Effective user ID: 유효 사용자
• 리눅스는 파일 접근 권한에 전용 파일 시스템 UID를 사용했었음
• 호환성을 이유로 아직도 지원이 됨. 프로세스는 geteuid(2)를 통해 EUID를 얻을 수 있다.
  • 저장된 SUID
    • 저장된 SUID는 프로세스가 실제 UID와 저장된 SUID 사이에서 유효 UID를 전환함으로써 권한을 가정할 수 있을 때 사용된다.
    • 예를 들어 프로세스가 특정 네트워크 포트를 사용하도록 허용하려면 root로 실행되는 것처럼 높은 권한이 필요하다.
  • FUID(파일시스템 UID): 리눅스 전용 ID, 파일 접근 권한을 결정하는 데 사용
    • 프로그램은 일반적으로 이 uid를 직접 조작하지 않는다. 커널은 euid가 변경되는 시기를 추적하고, 이에 따라 파일 시스템 uid를 자동으로 변경한다.
• 이는 일반적으로 파일 시스템 uid가 euid와 동일하다는 의미지만 이는 setfsuid(2)를 통해 변경할 수 있다.

기본 개요

• 파일시스템 트리: 디렉터리와 파일이라는 두 가지 유형의 객체
  • 디렉터리: 파일을 그룹화할 수 있는 조직의 단위
• 디렉터리: 트리의 노드
• 파일/디렉터리: 리프
• 권한이 내장되어 있다. 소유권이 있다. 소유권은 할당된 권한을 통해 파일과 디렉터리에 대한 접근을 제어한다.
• 일반적으로 파일시스템은 커널에서 구현된다.

드라이브

• HDD, SSD,와 같은 (물리적) 블록 디바이스
• 가상 머신의 드라이브는 에뮬레이션 될 수도 있다.
• /dev/sda(SCSI 디바이스), /dev/sdb(SATA디바이스), /dev/hda(IDE 디바이스) 와 같은 식이다.

파티션

• 드라이브를 스토리지 섹터의 집합인 파티션으로 논리적으로 분할할 수 있다
• HDD에 두 개의 파티션을 생성한다면 /dev/sdb1와 /dev/sdb2로 표시되는 식이다.

볼륨

• 볼륨은 파티션과 비슷하지만 더 유연하며, 특정 파일시스템용으로 포맷되기도 한다.
• 특히 LVM(logical volume manager)을 쓰면, 여러 파티션을 하나로 묶거나 자유롭게 크기 조정 가능

슈퍼 블록

• 시스템이 포맷되면, 파일시스템의 시작 부분에 파일시스템의 메타데이터를 캡쳐하는 특수 섹션이 생긴다.
• 파일시스템의 유형, 블록, 상태, 블록당 아이노드 수 등이 담긴다.

아이노드

• 각각의 파일에 대한 메타데이터를 저장하는 구조체
• 파일명과 실제 데이터는 저장하지 않는다.
• 이 데이터는 디렉터리에 보관되며, 디렉터리는 아이노드를 파일명에 매핑하는 특별한 종류의 일반 파일이라 할 수 있다.

확인하는 방법

• $ lsblk --exlude 7: 의사(루프)디바이스를 제외한 모든 블록 디바이스를 나열한다.
• lsblk: 모든 블록 디바이스 나열
• fdisk, parted: 디스크 파티션 관리
• blkid: UUID와 같은 블록 디바이스 속성 표시
• hwinfo: 하드웨어 정보 표시
• file -s : 파일시스템과 파티션 정보 표시
• stat, df -i, ls -i: 아이노드와 관련된 정보 표시 및 목록 출력

링크

• 다른 이름의 파일을 참조하거나, 단축어(shortcut)제공하고 싶을 때
  하드링크: 아이노드를 참조하며, 디렉터리는 참조 불가. 또한 파일시스템이 서로 다르면 동작하지 않는다.
  심볼릭링크: 파일의 내용이 다른 파일의 경로를 나타내는 문자열인 특수파일

가상 파일 시스템(Virtual file system)

• 리눅스는 가상 파일시스템(VFS)라는 추상화를 통해 다양한 종류의 리소스(인메모리, 로컬 연결, 네트워크 스토리지)에 파일과 유사한 접근을 제공할 수 있다.
• 기본 개념은 클라이언트(시스템 콜)와 개별 파일 시스템 사이에 간접 계층을 도입하는 것이다.
• 구체적인 디바이스 또는 다른 리소스 유형을 위한 연산을 구현한다.
• VFS는 일반 작업(열기, 읽기, 찾기)을 실제 구현 세부사항과 분리한다.
• VFS는 파일 체계를 기반으로 클라이언트가 동일한 방법으로 리소스에 접근할 수 있게 해주는 커널의 추상화 계층

로컬 파일시스템

• ext3, XFS, FAT, NTFS

• 드라이버를 이용하여 HDD, SSD와 같은 로컬 블록 디바이스에 접근한다.

• 장기 저장 디바이스가 지원하지 않지만, 주 메모리(RAM)에 상주하는 tmpfs와 같은 인메모리 파일 시스템

• procfs와 같은 의사파일시스템 역시 본질적으로는 인메모리다. 커널 인터페이스와 디바이스 추상화에 사용된다.

• NFS, Samba, 넷웨어(Netware;노벨에서 만든 제품명) 등의 네트워크 파일 시스템

• 이런 파일시스템도 드라이버를 사용한다. 실제 데이터가 상주하는 저장 디바이스는 로컬이 아니라 원격으로 연결되어 있다.

• 이는 드라이브에 네트워크 작업이 포함됨을 의미한다.

• VFS의 구성을 설명하기는 쉽지 않다. 파일과 관련된 시스템 콜은 100개가 넘는다.

VFS 인터페이스를 구성하는 시스템 콜 분석

• 아이노드: chmod, chown, stat
• 파일: open, close, seek, truncate, read, write
• 디렉터리: chdir, getcwd, link, unlink, rename, symlink
• 파일시스템: mount, flush, chroot
• 그 외: mmap, poll, sync, flock
• 다양한 VFS 시스템 콜이 파일시스템 구현으로 보내진다. 그밖의 시스템콜은 VFS의 기본 구현으로 전달된다.

VFS 데이터 구조

• inode: 핵심 파일시스템 객체, 캡쳐 유형, 소유권, 권한, 링크, 파일 데이터를 포함하는 블록에 대한 포인터, 생성과 접근 통계 등
• file: 열려 있는 파일을 나타냄(path; 현재 위치와 아이노드 포함)
• dentry:디렉터리 항목; 부모와 자식 저장
• super_block: 마운트 정보를 포함한 파일시스템을 나타냄
• vfsmount, file_system_type 포함

논리 볼륨 관리자

• 파티션을 사용해 드라이브를 분할하는 방법
  • 하지만 특히 파티션은 (저장 공간 양을 변경하기 위한) 크기 조정이 필요할 때 사용하기 어렵다.
• LVM: 파일시스템과 물리 개체(EX: 드라이브 또는 파티션)간의 간접 계층을 사용한다.
• 리소스 풀링을 통해 위험이 없고, 중단시간(downtime)도 없는 확장과 자동스토리지 증설이 가능해진다.

물리 볼륨(PV)

• 디스크 파티션, 전체 디스크 드라이브, 기타 디바이스

논리 볼륨(LV)

• 볼륨 그룹(VG)에서 생성된 블록 디바이스, 개념적으로 파티션과 비슷하다.
• 논리 볼륨을 사용하려면, 먼저 논리 볼륨에 파일 시스템을 생성해야 한다. 사용 중 논리 볼륨의 크기를 쉽게 조정할 수 있다.

볼륨 그룹(VG)

• 물리 볼륨과 논리 볼륨 사이의 중개자. 불륨 그룹이란 공동으로 리소스를 제공하는 물리적 볼륨 풀이라고 생각하면 된다.

관리 도구

• PV 관리 도구: lvmdiskscan, pvdisplay, pvcreate, pvscan
• 볼륨 그룹 관리 도구: vgs, vgdisplay, vgcreate, vgextend
• 논리 볼륨 관리 도구: lvs, lvscan, lvcreate

lvm 명령어

• sudo lvscan: 논리 볼륨을 나열
• sudo vgs: 볼륨 그룹 표시
• sudo pvdisplay: 물리 볼륨 표시

파일시스템 작업

• 주어진 파티션이나 논리볼륨(lvm 사용하여 생성)에서 파일시스템을 생성하는 방법에 대해 설명
• 1. 파일시스템을 생성한 다음, 이를 마운트한다. -- 파일시스템 트리에 삽입한다. (파일시스템을 생성: 리눅스가 아닌 다른 운영체제에서는 이 단계를 포맷이라고도 함)
     파일 시스템 생성
• 즉, 파티션이나 볼륨을 입력으로 받아 파일시스템을 구성하는 관리적인 부분을 설정해야 한다는 의미다.
• 입력해야 할 필수 정보를 어떻게 수집할지 확실하지 않다면 표를 참조(5-1)
  • 모든 정보를 모았다면, mkfs를 사용해 파일시스템을 생성하자.
  • mkfs: 두 가지 기본 입력을 받는다.
    • 1) 생성하려는 파일 시스템 유형(범용 파일시스템 절에서 설명하는 옵션 중 하나 참조)
• 2) 파일 시스템을 생성하려는 디바이스(ex: 논리볼륨)
• mkfs -t ext4 \ /dev/some_vg/some_lv
  • ext4 유형의 파일 시스템을 생성한다.
  • 논리볼륨 /dev/some_vg/some_lv 에 파일시스템을 생성한다.
  • mkfs로 파일시스템을 만든 후에는 파일시스템 트리에서 사용할 수 있게 만들어줘야 한다.

파일 시스템 마운트

• 파일시스템 트리(/에서 시작)에 이를 연결한다.
• mount 명령으로 파일시스템을 연결한다.
• mount 두 가지 주 입력값
  • 1) 연결하려는 디바이스
  • 2) 파일시스템 트리 내의 위치
  • 3) 또 다른 입력값
    • 읽기 전용을 위한 마운트 옵션(-o) 사용
    • 파일시스템 트리에 디렉터리를 마운트 하기 위한 바인드 마운트(--bind) 등을 사용할 수 있다 (나중에 컨테이너에서 확인)
• 기존 마운트 목록 출력
  • $ mount -t ext4, tmpfs
  • 마운트 목록을 출력하지만, 특정 파일시스템 유형만 표시한다. (여기서는 ext4와 tmpfs)
  • 마운트예제: ext4 유형의 LVM VG /dev/mapper/elementary--vg-root가 루트에 마운트 된다.
• 이때 생성된 파일시스템 유형으로 마운트 되었는지를 반드시 확인해야 한다.

범용 파일 시스템 레이아웃

• 파일 시스템이 준비하고 나서 다음은 그 내용을 구조화할 방법을 찾는 것.
• 프로그램이 저장된 위치, 구성, 데이터, 시스템 데이터, 사용자 데이터와 같은 항목을 구조화할 수 있다.
• 이런 디렉터리 구성과 그 내용을 파일시스템 레이아웃이라 부른다.
• 공식적으로 이런 레이아웃은 파일시스템 계층구조 표준(Filesystem Hierarchy Standard;FHS)라고 한다.
• FHS는 구조와 내부에 들어갈 권장 파일 목록을 포함해 디렉토리를 정의한다.
• 리눅스재단에서 FHS를 유지, 관리하며 이는 리눅스 배포판이 따라야 하는 좋은 출발점이다.
• man hier

범용 최상위 디렉터리

• bin, sbin
  • 시스템 프로그램과 명령(일반적으로 /usr/bin과 /usr/sbin에 링크되어 있음)
• boot: 커널 이미지와 관련 구성요소
• dev: 디바이스(터미널, 드라이브 등)
• etc: 시스템 구성 파일/디렉터리
• home: 사용자 홈 디렉토리
• lib: 공유시스템 라이브러리
• mnt, media: 이동식 미디어용 마운트 지정(예:usb 스틱)
• opt: 배포판 지정 디렉터리, 패키지 관리자 파일을 호스팅할 수 있다.
• proc, sys: 커널 인터페이스
• tmp: 임시 파일용
• usr: 사용자 프로그램(일반적으로 읽기 전용)
• var: 사용자 프로그램(로그, 백업, 네트워크 캐시 등)

의사 파일시스템

• 파일시스템은 정보를 구조화하고 접근하는 훌륭한 방법이다.
• 의사파일시스템(pseudo filesystem)은 파일시스템인 것처럼 가장하여 일반적인 방식(ls, cd, cat)으로 상호작용 할 수 있지만,
  실제로는 커널 인터페이스를 래핑한 것이다.

인터페이스란

• 프로세스에 대한 정보
• 키보드 같은 디바이스와의 상호 작용
• 데이터 소스나 싱크로 사용할 수 있는 특수 디바이스 같은 유틸리티

procfs

• 리눅스는 유닉스로부터 /proc 파일시스템(procfs)을 물려받았다.
• 원래 의도는 커널에서 프로세스 관련 정보를 발행하여 ps나 free같은 시스템 명령에 사용할 수 있게 하는 것이다.
• 이는 구조에 대한 규칙이 거의 없고, 읽기-쓰기 접근이 허용되며 시간이 지나면서 많은 정보가 procfs에 편입됐다.
  • /proc/PID/의 프로세스별 정보, 이는 커널이 디렉터리를 통해 제공하는 프로세스 관련 정보로, PID를 디렉터리 이름으로 사용한다.
  • 마운트, 네트워크 관련 정보, TTY 드라이버, 메모리 정보, 시스템 버전, 가동 시간과 같은 기타 정보가

procfs의 프로세스별 정보(가장 중요한 것들만)

• 항목 / 유형 /정보

• attr / 디렉터리 / 보안속성

• cgroup / 파일 / 제어그룹

• cmdline / 파일 / 커맨드라인

• cwd / 링크 / 현재 작업 디렉터리

• environ / 파일 / 환경변수

• exe / 링크 / 프로세스 실행 파일

• fd / 디렉터리 / 파일디스크립터

• io / 파일 / 스토리지 I/O(바이트, 문자 읽기 쓰기)

• limits / 파일 / 리소스 한계

• mem / 파일 / 사용된 메모리

• mounts / 파일 / 사용된 마운트

• net / 디렉터리 / 네트워크 통계

• stat / 파일 / 프로세스 상태

• syscall / 파일 / 시스템 콜 사용량

• task / 디렉터리 / 작업별(스레드별) 정보

• tiners / 파일 / 타이머 정보

• $ cat /proc/self/status | head -10

• procfs는 저수준 디버깅이나 시스템 도구 개발에 매우 유용

sysfs

• procfs가 꽤 거친 반면
• /sys 파일 시스템(sysfs)은 커널이 표준화된 레이아웃을 사용하여 선택한 정보(예: 디바이스에 대한 정보)를 노출하는 리눅스 고유의 구조화된 방법
• block/ : 발견된 블록 디바이스의 심볼릭 링크다.
• bus/ : 커널에서 지원하는 각 물리버스 유형마다 한 개씩 하위 디렉터리가 있다.
• class/: 디바이스 클래스가 포함됨
• dev/: 두 개의 하위 디렉터리가 포함되어 있다. 블록 디바이스용 block/과 시스템의 문자 디바이스용 char/이며, 이는 major-ID:minor-ID로 구성된다.
• devices/: 커널은 디바이스를 트리 형태로 표현한 정보를 제공한다.
• firmware/: 이 디렉터리를 통해 펌웨어 관련 속성을 관리할 수 있다.
• fs/: 이 디렉터리에는 일부 파일시스템의 하위 디렉터리가 포함되어 있다.
• module/: 커널에 로드된 각 모듈의 하위 디렉터리를 찾을 수 있다.

디바이스

• devfs
• /dev 파일시스템(devfs)은 물리적 디바이스에서 난수 생성기나 쓰기 전용 데이터 싱크에 이르기까지 모든 디바이스를 나타내는 디바이스 특수 파일을 호스팅한다.