[Unix] CH3. File - ownership

3.1 Files in a multi-user environment

 

Users and ownerships

• UNIX 시스템의 모든 파일은 시스템의 사용자 중 한명이 소유하고 있다.
• 소유자는 보통 파일을 만든 유저이다.
• 소유자의 실제 identity
  • user-id (uid)
  • uid는 특정 유저네임과 연관된다.

 

 

Users and ownerships

• 각 유닉스 프로세스는 보통 프로세스를 시작한 유저의 uid와 관련된다.
• 파일이 만들어질 때, 시스템은 프로세스를 만든 uid를 참조하여 소유권을 설립한다.
• 소유권 변경 
  • superuser 또는 파일의 소유자 
  • superuser(username=root, uid=0)
• group
  • 각 user는 한 개 이상의 group에 속한다.
  • /etc/group에서 정의됨
  • 그룹의 실제적인 identity
    • group-id (gid)
    • gid는 특정 그룹명과 연관된다.
• gid, uid는 사용자가 시작한 프로세스로부터 상속된다.

 

 

Effective user and group ids

• Real user-id (ruid)
  • 프로세스를 시작한 유저의 uid
  • 프로세스의 실제 소유자

• Effect user-id (euid)
  • 특정 작업을 수행하기 위해 프로세스의 권한을 평가하는데 사용
  • 프로세스를 실행하고 있는 user (실제 권한자)
  • euid, egid로 파일 접근 결정
  • EUID는 SetUID 권한이 설정된 실행 파일에 의해 변경됨
  • EUID는 일시적으로 다른 계정의 UID를 저장
  • EUID에 저장된 UID에 따라 프로스세의 권한이 결정됨
• 대부분의 경우 ruid와 euid는 동일
• effective user와 group ID는 파일 접근 권한을 결정한다.

 

 

euid를 잠시 root로 변경

 

 

 

 

 

 

Permissions and file modes

• Ownership
  • file과 관련된 허가(permission)을 선택할 수 있다.
• Permission
  • 다른 user가 피일에 접근할 수 있는 방법을 결정
  • superuser는 read, write, execute에 상관없이 어떤 파일이든 조작 가능하다.

• -rwxrwxrwx 일 때, 앞의 -는 이 것이 파일임을 뜻한다. 디렉토리인 경우 drwxrwxrwx가 된다.

 

 

open( ) and file permissions

• 만약 이미 존재하는 파일을 여는데 open()을 사용하면
  • 시스템은 파일의 권한을 확인하여 프로세스에서 요청한 액세스 모드가 허용되는지 확인한다.
  • 프로세스에 요청된 액세스 권한이 없는 경우 open은 -1을 반환한다.
  • 파일을 열면 커널은 effective user과 group IDs를 기반으로 액세스 테스트를 수행한다.

0600같은 권한은 O_CREAT할때만 지정 가능

O_CREAT가 지정되어 있고, O_EXCL을 지정했을 때, pathname이 이미 존재하는 파일이면 오류 발생

 

 

Extra permission for executable files

• 일반적으로 파일에 실행 프로그램이 포함된 경우에만 관련
  • data file에는 상관 없고, program file에만 상관 있음

 

 

 

 

<- 거의 사용되지 않음 

 

• 만약 S_ISUID permission가 설정되어 있고, 실행 파일이 시작하면 euid는 그 프로그램 파일의 owner가 된다.

 

 

 

 

 

 

 

-> user을 superuser로 바꾸라

 

-> set user id가 설정되어 있으며 user의 실행 권한이 있다는 뜻

 

 

 

 

 

 

특수권한

 

 

 

 

 

 

 

 

 

 

 

 

 

[사진 출처: https://eunguru.tistory.com/115]

 

• setuid 비트
  • setuid 비트를 실행 파일에 적용하면 euid가 실 사용자(프로그램을 실제 실행 중인 사용자)에서 프로그램 소유자의 ID로 변경된다.
  • setuid 비트를 언제 사용?
    • superuser인 root만 접근할 수 있는 파일이나 명령에 대한, 일반 사용자로 접근하는 것이 불가능한 경우
    • setuid하면 uid가 평생 바뀌는게 아니라 파일 실행 순간만 그 파일의 소유자 권한으로 실행하는 것임.
  • setuid 비트 설정 방법
    • [chmod u+s file1]: user한테 setuid
  • setuid 설정하면, user의 실행 권한이 있으면 그 자리에 's'로 표시되고, 실행 권한 없으면 'S'로 표현됨
• sticky 비트
  • sticky 비트는 특정 디렉토리를 누구나 자유롭게 사용 할 수 있게 하기 위함
  • S_ISVTX 비트는 실행 파일에서 실행할 수 있는 비트이다.
  • 초기 시스템에 STICKY 비트가 설정되어 있으면, 그 파일이 수행된 후 program-text 부분이 시스템이 정지할 때까지 시스템의 swap 영역에 남아있다.
  • 단, sticky 비트가 디렉토리에 적용되면 디렉토리 소유자나 파일 소유자 또는 슈퍼유저가 아닌 사용자들은 파일을 삭제하거나 이름을 변경하지 못하도록 막음, 파일 또는 디렉토리 생성은 누구나 할 수 있음
  • sticky 비트를 공유 모드라고도 함

 

 

어떻게 비밀번호를 변경할 수 있을까?

<- user만 겨우 read할 수 있음

 

 

 

• /etc/shadow는 root만 접근 가능하므로 우리가 바로 변경할 수 없다.
• 하지만 usr/bin/passwd를 통해 etc/shadow을 변경할 수 있다.

 

<- S_ISUID 설정됨

 

 

 

 

passwd 실행파일의 소유주는 현재 root이며,  S_ISUID가 설정되어 있으므로 

passwd를 실행 시키면 euid는 이 프로그램의 소유자인 root 권한을 얻게 된다.

euid가 root 권한을 얻게 되었으므로 /etc/shadow에 접근 가능해진다.

 

umask()

• 우리가 파일을 O_CREAT 모드를 설정하고 열 때, 
• filedesc=open(pathname, O_CREAT,mode)는 
• filedesc=open(pathname,O_CREAT,(~mask)&mode)와 같다
• 즉, 우리가 mode 지정한대로 무조건 허가(permission)가 설정되는 것이 아니라 umask에 의해 특정 권한은 불허될 수 있는 것이다. 
• umask는 이 umask를 지정할 수 있는 함수이다.
• 만약 oldmask=umask(022);이렇게 설정하면 // 022=--- -w- -w-
  • group과 others는 write을 못하게된다.

 

access()

• 0 반환: 접근 권한 있다, -1반환: 접근 권한 없다
• ruid, rgid를 기반으로 pathname에 접근 권한 있는지 확인
• amode:
  • R_OK: read 권한을 위한 테스트
  • W_OK: write 권한을 위한 테스트
  • X_OK: excute 권한을 위한 테스트
  • F_OK: 파일이 존재하는지 테스트

 

chmod()

• 허가(permission)을 변경
• 파일의 owner와 superuser만 변경 가능
• 사용법: [chmod u+w test.c] - test.c 파일의 user에게 write 권한을 준다

 

chown()

• 파일의 uid나 gid를 변경한다
• 인자
  • owner_id: 새로운 owner
  • group_id: 새로운 group
• 파일의 소유권이 바뀌면 set-user-id와 set-group-id 설정은 꺼진다.

 

File with multiple names

VFS의 네가지 주요 객체

• The superblock object
  • 마운트시킨 파일 시스템 정보를 저장
  • disk-based filesystem을 위해서 이 object는 보통 disk에 저장된 filesystem control block 에 해당
• The inode object
  
  • 특정 파일에 대한 일반 정보를 저장
  • disk-based filesystem을 위해서 이 object는 보통 disk에 저장된 filesystem control block에 해당
  • 각 object는 inode number를 가짐
• The file object
  
  • 열린 파일과 프로세스 사이의 상호 작용과 관련한 정보 저장
  • 이 정보는 단지 각 프로세스가 파일을 접근한 동안만 kernel memory에 존재
• The dentry object
  
  • 디렉토리 항목과 대응하는 파일간 연결에 대한 정보 저장
  • 각 디스크 기반 파일 시스템에서는 독특한 방법으로 정보를 디스크에 저장

 

Unix file system

• Boot block

  • Unix가 처음 실행할 때 사용하는 boot code 

  • unix를 부팅하는 block

• Super block

  • 파일 시스템 내의 전체 블락 수 

  • inode free list에 있는 inodes 수 (사용 가능한 inodes 수)

  • free blocks의 bit map

  • block size (byte)

  • free block의 수 

  • 사용 중인 block의 수

• i-node

  • 디스크에 있는 파일과 연관된 모든 inode

  • 파일을 유니크하게 식별

• data blocks

  • 파일 블락을 저장하기 위함

i-node

• 각 파일은 하나의 inode를 가지고, 적어도 하나의 디렉토리와 link를 가진다.

• i-node가 0: no i-node (삭제되었다는 뜻, 사용 가능)

• i-node가 1: 사용 불가

• i-node가 2: root directory

• i-node는 3번부터 실질적으로 사용

• pointers

  • inode가 128bytes, 포인터는 4bytes, 상태 정보는 68 byte이고, block size가 8K bytes, block pointer가 각각 32 bits라고 가정하자.

  • inode에 포인터를 위한 공간이 얼마나 있는가?

    • (128-68)=60 bytes 사용 가능

    • 이 때, 포인터는 한 개에 4byte이므로 60/4=15개의 포인터를 가질 수 있다

  • direct pointers로 얼마나 큰 파일을 나타낼 수 있는가?

    • 15X8K=120K (direct pointers로 가능한 최대 파일 크기)

  • indirect pointer를 사용한다면

    • 파일 하나가 8k니까 포인터 크기로 나누면 2k개의 포인터를 만들 수 있다.
    • 각 포인터가 또 8k 크기의 파일들을 가리키므로 총 2K*8K 크기의 파일을 만들 수 있다.

 

Hard link

• 파일을 direct로 가리키는 포인터이다
• 원본 파일과 동일한 inode를 가진다
  • 하나의 파일이 서로 다른 path name을 갖는 것이다.
• Link count는 i-node를 가리키는 디렉토리 엔트리 수이다
• link count가 0이되면 파일은 삭제된 것이다.
• 다른 파일 시스템에 hard link를 할 수 없다.
• superuser만이 디렉토리에 하드 링크를 만들 수 있다.

 

Symbol link

• 파일을 indirect로 가리키는 포인터이다
• 원본 파일과 다른 새로운 inode를 갖는다
  • 새로운 파일을 하나 만드는 것
  • 이 파일은 원본 파일의 path-string을 갖는다
• 파일 시스템 제한이 없다 -> 다른 파일 시스템에 있는 파일을 symbol link할 수 있음

 

 

link() <- hard link

• 새로운 디렉토리 엔트리를 만들고 link count를 증가시킨다

 

unlink()

• 존재하던 디렉토리 엔트리를 지운다
• 단지 link name을 지우고, 파일의 link count를 1 감소시킨다.
• 모든 link를 지워 link count가 0이 되면 파일은 지워진다.
  • free block list에 추가됨
• unlink permission:
  • 파일 permission이랑은 관련 없음, 디렉토리 허가에 의해서만 결정됨
  • 디렉토리의 쓰기, 실행 권한이 필요하다

 

symlink()

• symbolic link file은 실제 이름 경로로 파일을 open한다
• datablock 안에 link 하고자하는 파일의 full name이 있다.

 

 

readlink()

• readlink 시스템 콜이 호출되면
  1. sympath가 열린다
  2. 버퍼에 있는 파일 내용을 읽는다
  3. sympath가 닫힌다.
• 만약 원본 파일이 삭제되면, symbolic link는 볼 수 있지만 open 콜은 불가능하다

 

 

파일 정보 얻기: stat and fstat

stat()

• stat: pathname에 지정한 파일의 정보를 검색해 buf로 지정한 구조체에 저장
• fstat: 현재 열려 있는 파일의 파일 디스크립터를 인자로 받아 정보를 검색한 후 buf로 지정한 구조체에 저장
• lstat: symbolic link에 대한 정보 저장 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

출처: [Unix system programming]

출처: https://akaseon.tistory.com/55

출처: https://eunguru.tistory.com/115