개념 사전/시스템 · 서버 / 계정·접근 통제
개념 사전 · 개념

Linux 권한과 umask

리눅스 파일 권한 · 유닉스 권한 · umask

기본 파일 권한은 소유자·그룹·기타 세 범주에 읽기·쓰기·실행 비트를 지정하는 접근 통제다. 의 자격 정보로 적용 범주를 선택하며 는 새 파일 생성 시 요청 모드에서 허용 비트를 지우는 기본 제한이다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 파일 내용과 디렉터리 이름 탐색·변경을 실행 주체별로 제한한다.
  • 공동 작업 디렉터리의 소유 그룹과 생성 기본 권한을 설계한다.
  • 서비스가 어떤 계정으로 실행되어 어떤 파일을 사용하는지 판단한다.

02어떤 순서로 동작하나

  1. 동작 확정

    파일 읽기인지 이름 삭제인지 디렉터리 통과인지에 따라 필요한 비트를 구분한다.

  2. 자격 정보 비교

    파일 접근용 UID와 소유자 UID를 먼저 비교하고, 일치하지 않으면 파일 그룹과 그룹을 비교한다.

  3. 한 범주 판정

    선택된 ·group·other 비트에 필요한 권한이 모두 있는지 검사하며 부족하다고 다른 범주를 더하지 않는다.

  4. 추가 조건 적용

    ·capability··읽기 전용 마운트 같은 조건도 적용되어 최종 파일 연산의 성공 또는 거부가 결정된다.

03먼저 알아둘 용어와 구성요소

각 권한은 r=4, w=2, x=1의 비트다.
디렉터리의 r은 이름 목록 읽기, x는 이름을 통해 내부 객체 탐색, w는 항목 생성·삭제·이름 변경에 관여한다.
일반 모드 비트 판정에서 의 파일 접근용 사용자 ID가 파일 소유자와 일치하면 소유자 비트만 적용한다.
소유자가 아니면서 파일 그룹이 의 유효 그룹 또는 보조 그룹 중 하나와 일치하면 그룹 비트를 적용하고, 그 밖의 경우 기타 비트를 사용한다.
프로그램이 요청한 생성 모드에서 에 설정된 비트를 제거한다.
sticky 디렉터리에서는 쓰기 권한이 있더라도 파일 소유자·디렉터리 소유자 또는 필요한 권한을 가진 만 해당 항목을 삭제·이름 변경할 수 있다. /tmp의 1777이 대표 사례다.
LEARN THROUGH PRACTICE

SetGID 디렉터리의 그룹 상속과 실제 쓰기 권한 구별하기

그룹 목록과 디렉터리 모드의 변화를 연결해, 새 항목의 그룹을 정하는 규칙과 생성 가능 여부를 분리한다.

실습 구성과 전제

  • 파일 시스템에 디렉터리와 사용자·그룹이 준비된 실습을 해석한다. 계정 예시는 labuser·labteam으로 재구성한다.
  • 디렉터리 변경 화면은 root가 실행한 결과다. 일반 사용자의 쓰기 성공을 보여 주는 화면으로 해석하지 않는다.

  1. 계정이 가진 그룹부터 확인한다

    • id의 gid는 기본 그룹, groups는 기본·보조 그룹 목록을 보여 준다. 이름과 숫자 GID를 함께 읽어 디렉터리의 소유 그룹과 대응시킨다.
    • 화면의 한 계정은 자신의 기본 그룹 외에 tester 그룹에도 포함된다. 이 정보는 그룹 권한을 적용할 후보라는 뜻이며, 아직 해당 디렉터리에 쓰기가 가능하다는 뜻은 아니다.
    bash
    id labuser
getent group labteam
id

    계정 데이터베이스 조회와 현재 자격 정보를 비교하는 명령이다.

    Linux 사용자와 특수 권한 · 그룹 생성 및 관리 (6)원본 크기로 보기 ↗
    • id 출력의 uid와 gid가 각각 표시되고 groups에는 두 그룹이 나열된다.
    • groups 명령에서도 기본 그룹 외에 tester가 보이므로 보조 그룹 소속을 확인할 수 있다.
    확인 기준

    조회 대상 계정의 그룹과 현재 로그인 셸의 그룹이 다르면, 그룹 변경 이후 새 로그인 세션인지 먼저 구분한다.

  2. 2755를 그룹 상속과 접근 비트로 분해한다

    • chgrp 뒤 소유 그룹이 바뀌고 chmod 2755 뒤 그룹 실행 자리의 x가 s로 바뀐다. 앞의 2는 SetGID, 뒤의 755는 소유자 rwx·그룹 r-x·기타 r-x다.
    • 부모 디렉터리의 SetGID 때문에 그 안에 만든 항목은 부모의 그룹을 상속한다. 새 하위 디렉터리에 SetGID도 이어지는 모습이 화면에서 확인된다.
    Linux 사용자와 특수 권한 · 디렉터리 그룹 권한 설정 (10)원본 크기로 보기 ↗
    • test2는 처음 root:root였다가 chgrp 뒤 root:tester로 바뀐다.
    • chmod 2755 뒤 test2와 그 안의 test3 모두 drwxr-sr-x이고, 소유 그룹도 tester로 표시된다.
    확인 기준

    그룹 이름의 상속은 확인되지만 2755의 그룹 비트에는 w가 없다. 그룹 구성원의 생성 권한까지 성공했다고 결론내리지 않는다.

  3. 생성 권한은 디렉터리의 w와 x로 별도 판단한다

    • 일반 사용자가 새 이름을 만들려면 부모 디렉터리에 쓰기와 검색 권한이 필요하다. 경로 앞부분의 검색 권한, , 같은 추가 조건도 통과해야 한다.
    • 재구성 환경에서 그룹 협업이 목적이라면 2770처럼 그룹에 wx가 있는 설계를 검토한다. 이는 화면의 2755와 다른 권한 설정이므로 동일 결과로 섞지 않는다.
    bash
    stat -c "%A %a %U:%G %n" /srv/lab-share
getfacl /srv/lab-share
namei -l /srv/lab-share

    실습 디렉터리의 모드··상위 경로를 조회하는 재구성 예시다.

    확인 기준

    stat의 2755와 getfacl의 유효 권한을 함께 읽고, root의 생성 성공과 일반 계정의 접근 판정을 따로 기록한다.

실습에서 확인한 동작 원리

  • SetGID는 새 항목의 그룹 상속을 제어하며, 그룹의 쓰기 권한을 자동으로 추가하지 않는다.
  • id의 그룹 목록, 디렉터리 소유 그룹, 모드 비트를 같은 요청에 대입해야 접근 결과를 설명할 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

passwd 필드와 id 출력으로 로그인 자격 정보 추적하기

계정 레코드, 보조 그룹 소속, 실제 의 자격 정보를 서로 다른 증거로 읽는다.

실습 구성과 전제

  • 세 화면은 서로 다른 계정·시스템의 조회 사례다. 한 계정에 그룹을 추가한 연속 전후 사진이 아니다.
  • 계정 데이터는 읽기 전용으로 조회한다. 아래 labuser·labteam은 실제 계정명을 대신한 예시다.

  1. 계정 레코드의 필드를 나눈다

    • passwd 형식은 이름:암호표시:UID:GID:설명:홈:셸이다. x는 보통 가 별도 shadow 데이터에 있다는 표시이며, 사용자 암호 자체가 아니다.
    • 서비스 계정의 nologin과 일반 계정의 bash를 비교하면 대화형 로그인 용도를 구분할 수 있다. 셸 설정만으로 모든 인증 방식이나 서비스 실행을 금지했다고 단정하지 않는다.
    bash
    getent passwd labuser
getent group labteam

    계정·그룹 레코드를 조회한다. shadow 해시를 출력할 필요는 없다.

    9/1 - beat, nessus · 실습·개념 참고 화면 25원본 크기로 보기 ↗
    • 화면의 레코드들은 콜론으로 구분되며 UID·GID·홈 경로·셸이 연속해 나온다.
    • 서비스 계정에는 nologin, 일반 계정에는 /bin/bash가 나타나므로 계정 목적에 따른 차이를 읽을 수 있다.
    확인 기준

    getent는 시스템의 이름 조회 설정을 따른다. /etc/passwd에 없더라도 외부 계정 저장소에서 조회되는 계정이 있을 수 있다.

  2. 기본 그룹과 보조 그룹 목록을 대조한다

    • 첫 화면의 user2는 groups에 자신의 그룹 하나가 보인다. 두 번째 user1은 자신의 그룹과 tester가 함께 보인다. 이 둘은 서로 다른 계정의 구성 비교다.
    • passwd의 GID 한 필드만 읽어서는 보조 그룹까지 알 수 없다. id 대상계정 출력으로 전체 그룹 목록을 보완한다.
    Linux 사용자와 특수 권한 · 기본 그룹과 보조 그룹 (2)원본 크기로 보기 ↗
    • uid=1001, gid=1001이 표시된다.
    • groups에는 1001 그룹 하나만 나열되어 있다.
    Linux 사용자와 특수 권한 · 그룹 생성 및 관리 (6)원본 크기로 보기 ↗
    • 다른 계정의 기본 GID는 1002다.
    • groups에는 1002 외에 1003(tester)가 함께 나열된다.
    확인 기준

    동명이인 그룹을 피하려면 이름뿐 아니라 숫자 GID도 대조한다. 현재 셸의 그룹 상태와 조회 대상 계정의 목록도 구별한다.

  3. 새 로그인 전후를 프로세스 관점에서 확인한다

    • 보조 그룹을 바꾼 뒤 기존 셸이 자동으로 새 자격 정보를 얻는 것은 아니다. 새 세션은 계정 조회 결과를 바탕으로 새 의 그룹 목록을 설정한다.
    • id labuser와 인자 없는 id를 나란히 기록한다. 전자는 지정 계정의 소속 조회이고 후자는 명령을 실행한 현재 의 자격 정보이므로 결과가 다를 이유가 있다.
    bash
    id labuser
id
printf "effective UID: "; id -u
printf "group IDs: "; id -G

    현재 세션과 지정 계정의 자격 정보 비교 예시다.

    확인 기준

    새로 로그인한 대상 계정에서 id를 다시 확인해 그룹이 반영되었는지 판단한다. 로 실행한 결과를 일반 로그인 상태와 섞지 않는다.

실습에서 확인한 동작 원리

  • 계정 레코드는 로그인에 사용할 신원 정보이고, 접근 판정에는 실행 중 의 자격 정보가 쓰인다.
  • 기본 GID 한 개와 보조 그룹 집합은 역할이 다르며, 그룹 변경의 적용 시점은 새 세션 생성과 연결된다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 0640은 의 rw-, group의 r--, other의 ---를 뜻하므로 모든 사용자가 읽을 수 있는 값이 아니다.
  • 일반 파일 생성 요청 0666에 0027을 적용하면 비트 제거 결과가 0640이다. 정수 666에서 27을 빼는 계산이 아니다.
  • 파일 내용 쓰기가 금지돼도 부모 디렉터리에서 쓰기와 탐색이 허용되면 이름 삭제가 가능할 수 있으며 가 이를 추가 제한한다.

05혼동하기 쉬운 점과 확인 기준

  • 파일 w는 내용 변경, 부모 디렉터리 w+x는 이름 변경·삭제와 관계한다. 파일을 읽기 전용으로 만들어도 부모에서 삭제를 허용하는 조건은 남을 수 있다.
  • 터미널의 id와 서비스 UID·그룹이 다르면 같은 경로의 결과도 달라진다. 파일 이름을 바꾸기 전에 거부된 요청의 실행 주체와 동작을 고정한다.
  • 이 허용해도 읽기 전용 마운트, , 서비스 자체 정책에서 쓰기가 실패할 수 있다. 이때 mask를 계속 넓히면 접근 범위만 불필요하게 커진다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

Linux 권한·ACL·특수 권한파일과 디렉터리의 r·w·x는 의미가 다릅니다. 소유권, 그룹, ACL과 추가 접근 통제를 순서대로 확인합니다.상세 노트 읽기 →사용자·그룹과 최소 권한사용자 이름은 식별자를 읽기 쉽게 표현한 것입니다. 서비스 계정과 관리 계정을 분리하고 필요한 권한만 부여합니다.상세 노트 읽기 →SELinux의 정책·컨텍스트와 거부 분석일반 파일 권한이 허용해도 SELinux 정책이 접근을 거부할 수 있습니다. 모드와 컨텍스트, 거부 로그를 연결해 원인을 찾습니다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.