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

Linux 사용자·그룹과 실행 자격

리눅스 사용자와 그룹

사용자는 UID, 그룹은 GID로 식별되며 는 이 숫자들과 보조 그룹 목록을 실행 자격으로 가진다. 계정 데이터베이스를 바꾼 상태와 이미 실행 중인 가 가진 자격 정보는 같지 않을 수 있다.

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

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

  • 사람과 서비스의 파일 소유권 및 실행 권한을 분리한다.
  • 공유 그룹으로 여러 계정의 협업 범위를 표현한다.
  • 로그인·원격 접속·서비스 실행에서 실제 작업 주체를 결정한다.

02어떤 순서로 동작하나

  1. 계정 조회

    설정에 따라 로컬 파일이나 디렉터리 서비스에서 이름과 UID·GID 등의 정보를 조회한다.

  2. 인증과 계정 조건 검사

    선택한 로그인 경로가 자격 증명과 계정 만료·로그온 허용 조건을 검사한다.

  3. 설정

    은 UID·기본 그룹·보조 그룹을 설정하고 이후 생성하는 가 이를 이어받는다.

  4. 자원 접근

    커널은 그 의 현재 자격 정보를 파일 소유권·과 비교하며 저장소의 그룹 수정이 기존 세션에 자동 반영되는 것은 아니다.

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

/etc/의 한 줄은 이름:암호표시:UID:GID:설명:홈:로그인셸의 일곱 필드다.
/etc/는 와 암호 변경·만료 정보를 관리하므로 공개 본문이나 로그에 내용 자체를 옮기지 않는다.
/etc/은 그룹 이름과 GID, 보조 구성원을 담는다.
getent는 설정에 따라 로컬 파일뿐 아니라 SSSD· 등 외부 계정 공급자를 포함하여 조회한다.
에는 real/effective/saved UID·GID와 보조 그룹 집합 등이 있다. 파일 접근에는 의 fsuid/fsgid도 관계하며 일반적으로 effective 값과 함께 움직인다.
계정 만료일은 암호 만료와 별도이며 PAM과 서비스가 이 상태를 어떻게 검사하는지도 인증 경로에 영향을 준다.
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. 계정 레코드의 필드를 나눈다

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

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

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

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

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

    • 첫 화면의 user2는 groups에 자신의 그룹 하나가 보인다. 두 번째 user1은 자신의 그룹과 tester가 함께 보인다. 이 둘은 서로 다른 계정의 구성 비교다.
    • 의 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예제로 따라가기

  • 사용자를 team 그룹에 추가한 뒤 id learner는 새 저장소 목록을 보여도 기존 셸의 id는 이전 보조 그룹을 보일 수 있다.
  • nologin은 대화형 로그인 제한에 관계하며 별도 인증 경로를 사용하는 파일 공유까지 일괄 금지하는 명령은 아니다.
  • 계정을 삭제해도 그 UID가 소유한 파일은 남을 수 있다. 동일 숫자 UID를 다시 배정하면 새 계정이 그 소유권과 연결될 수 있다.

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

  • 저장된 암호 잠금 상태는 암호 인증의 근거다. 공개키와 이미 발급된 세션 등 다른 경로가 같은 조건으로 막히는지는 서비스·PAM 정책에 달렸다.
  • 인증이 성공해도 파일의 UID/GID· 또는 명령 위임이 맞지 않으면 작업은 거부된다. 로그인 로그의 success를 후속 작업의 성공으로 합치지 않는다.
  • 이름을 삭제한 뒤에도 숫자 UID가 붙은 파일과 실행 는 남을 수 있다. 소유권 인계와 UID 재사용을 함께 관리해야 다른 계정으로 자료가 연결되는 일을 피할 수 있다.

06상세 노트 · 실습 자료

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

사용자·그룹과 최소 권한사용자 이름은 식별자를 읽기 쉽게 표현한 것입니다. 서비스 계정과 관리 계정을 분리하고 필요한 권한만 부여합니다.상세 노트 읽기 →Linux 권한·ACL·특수 권한파일과 디렉터리의 r·w·x는 의미가 다릅니다. 소유권, 그룹, ACL과 추가 접근 통제를 순서대로 확인합니다.상세 노트 읽기 →SSH 인증·호스트 키와 연결 진단SSH에서는 서버가 누구인지 확인하는 단계와 사용자가 접속 권한을 증명하는 단계를 구분합니다.상세 노트 읽기 →

공식 문서 · 표준

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