IT 관련/우분투(Ubuntu) 이것저것

우분투(리눅스)의 권한(Permission)관련 정리

islet2 2025. 4. 4. 14:39

우분투(및 리눅스 전반) 시스템의 핵심 요소인 '권한(Permission)'에 대해 명확하고 체계적으로 정리해 드리겠습니다. 어렵게 느껴질 수 있지만, 기본 원리를 이해하면 시스템을 안전하고 효율적으로 관리하는 데 큰 도움이 될 것입니다. 핵심 개념 위주로 단계별로 진행하며 실용적인 예제를 통해 확실히 이해하실 수 있도록 돕겠습니다.


1단계: 권한의 기본 개념 이해하기

우분투는 다중 사용자 시스템입니다. 즉, 여러 사람이 하나의 시스템을 동시에 사용할 수 있습니다. 이때 각 사용자나 그룹이 특정 파일이나 디렉토리에 접근하고 조작할 수 있는 범위를 정하는 것이 바로 '권한'입니다. 권한은 시스템 보안의 가장 기본적인 요소입니다.

핵심 요소:

  1. 사용자 (User): 시스템에 로그인하는 개별 계정입니다.
  2. 그룹 (Group): 여러 사용자를 묶어 관리하는 단위입니다. 특정 그룹에 속한 사용자들은 해당 그룹에 부여된 권한을 공유합니다.
  3. 파일/디렉토리 소유권: 모든 파일과 디렉토리에는 소유자(User Owner)와 소유 그룹(Group Owner)이 지정되어 있습니다.

권한의 대상:

권한은 다음 세 가지 대상에게 각각 부여됩니다.

  1. 소유자 (User/Owner): 파일이나 디렉토리를 생성한 사용자 (기본값). u로 표기.
  2. 그룹 (Group): 파일이나 디렉토리의 소유 그룹에 속한 사용자들. g로 표기.
  3. 다른 사용자 (Others): 소유자도 아니고, 소유 그룹에도 속하지 않은 나머지 모든 사용자. o로 표기.
  4. 모든 사용자 (All): 소유자, 그룹, 다른 사용자 모두를 지칭. a로 표기 (주로 chmod 명령어에서 사용).

2단계: 권한의 종류 이해하기

세 가지 기본 권한이 있습니다:

  1. 읽기 (Read - r):

    • 파일: 파일의 내용을 읽거나 볼 수 있습니다. (예: cat, less, more 명령어 사용)
    • 디렉토리: 디렉토리 안에 어떤 파일이나 하위 디렉토리가 있는지 목록을 볼 수 있습니다. (예: ls 명령어 사용)
  2. 쓰기 (Write - w):

    • 파일: 파일의 내용을 수정하거나 덮어쓸 수 있습니다. 파일 크기를 변경할 수도 있습니다.
    • 디렉토리: 디렉토리 안에서 파일을 생성, 삭제, 이름 변경 등을 할 수 있습니다. (주의: 디렉토리에 대한 쓰기 권한은 해당 디렉토리 안의 파일/디렉토리 생성/삭제 권한이지, 디렉토리 자체를 삭제하는 권한이 아닙니다.)
  3. 실행 (Execute - x):

    • 파일: 파일을 프로그램이나 스크립트로 실행할 수 있습니다.
    • 디렉토리: 디렉토리 안으로 들어갈 수 있습니다 (cd 명령어 사용). 디렉토리 내 파일에 접근하려면 해당 디렉토리에 대한 실행 권한이 필요합니다.

3단계: 권한 확인하기 (ls -l 명령어)

터미널에서 ls -l 명령어를 사용하면 파일과 디렉토리의 상세 정보와 함께 권한을 확인할 수 있습니다.

예시:

$ ls -l my_script.sh my_document.txt my_directory/
-rwxr-xr-- 1 john users 1024 Jan 15 10:30 my_script.sh
-rw-rw---- 1 john admin  512 Jan 15 10:31 my_document.txt
drwxr-x--- 1 jane users 4096 Jan 15 10:32 my_directory/

출력 분석:

출력의 첫 번째 필드가 권한 정보를 나타냅니다. 총 10자리로 구성됩니다.

  • 첫 번째 문자: 파일 유형
    • -: 일반 파일
    • d: 디렉토리
    • l: 심볼릭 링크
    • (그 외 c, b, p, s 등 특수 파일 유형도 있습니다)
  • 다음 9개 문자: 권한 정보 (세 글자씩 묶어서 소유자, 그룹, 다른 사용자 순서)
    • r: 읽기 권한 있음
    • w: 쓰기 권한 있음
    • x: 실행 권한 있음
    • -: 해당 권한 없음

예시 해석:

  1. my_script.sh (-rwxr-xr--)
    • -: 일반 파일
    • rwx: 소유자(john)는 읽기, 쓰기, 실행 가능 (rwx)
    • r-x: 그룹(users)은 읽기, 실행 가능 (rx)
    • r--: 다른 사용자는 읽기만 가능 (r)
  2. my_document.txt (-rw-rw----)
    • -: 일반 파일
    • rw-: 소유자(john)는 읽기, 쓰기 가능 (rw)
    • rw-: 그룹(admin)은 읽기, 쓰기 가능 (rw)
    • ---: 다른 사용자는 아무 권한 없음
  3. my_directory/ (drwxr-x---)
    • d: 디렉토리
    • rwx: 소유자(jane)는 목록 보기(r), 파일 생성/삭제(w), 디렉토리 진입(x) 가능
    • r-x: 그룹(users)은 목록 보기(r), 디렉토리 진입(x) 가능 (파일 생성/삭제 불가)
    • ---: 다른 사용자는 아무 권한 없음

4단계: 권한 변경하기 (chmod 명령어)

chmod (change mode) 명령어를 사용하여 파일이나 디렉토리의 권한을 변경할 수 있습니다. 두 가지 방식이 주로 사용됩니다.

1. 심볼릭(Symbolic) 방식: 직관적이고 특정 권한만 변경할 때 유용합니다.

  • 형식: chmod [대상][연산자][권한] 파일/디렉토리

    • 대상: u (소유자), g (그룹), o (다른 사용자), a (모두)
    • 연산자: + (권한 추가), - (권한 제거), = (권한 설정)
    • 권한: r (읽기), w (쓰기), x (실행)
  • 예제:

    • my_script.sh 파일에 소유자의 실행 권한 추가:
      chmod u+x my_script.sh
    • my_document.txt 파일에서 그룹의 쓰기 권한 제거:
      chmod g-w my_document.txt
    • public_info 디렉토리에 다른 사용자의 읽기 및 실행 권한만 설정 (기존 권한 무시):
      chmod o=rx public_info
    • shared_file 파일에 모든 사용자의 읽기 권한 추가:
      chmod a+r shared_file
    • config.cfg 파일의 권한을 소유자=rw, 그룹=r, 다른 사용자= 없음으로 설정:
      chmod u=rw,g=r,o= config.cfg

2. 8진수(Octal) 방식: 숫자를 사용하여 권한을 한 번에 설정합니다. 빠르고 간결합니다.

  • 권한 숫자 매핑:

    • r = 4
    • w = 2
    • x = 1
    • 권한 없음 = 0
  • 각 대상(소유자, 그룹, 다른 사용자)의 권한 숫자를 더하여 세 자리 숫자로 만듭니다.

    • rwx = 4 + 2 + 1 = 7
    • rw- = 4 + 2 + 0 = 6
    • r-x = 4 + 0 + 1 = 5
    • r-- = 4 + 0 + 0 = 4
    • --- = 0 + 0 + 0 = 0
  • 형식: chmod [세 자리 숫자] 파일/디렉토리

  • 예제:

    • my_script.sh 파일 권한을 rwxr-xr-- (754)로 변경:
      chmod 754 my_script.sh
    • my_document.txt 파일 권한을 rw-r----- (640)로 변경:
      chmod 640 my_document.txt
    • my_directory 디렉토리 권한을 rwxr-x--- (750)로 변경:
      chmod 750 my_directory
    • 일반적인 권장 권한:
      • 일반 파일: 644 (rw-r--r--) 또는 664 (rw-rw-r--)
      • 실행 파일/스크립트: 755 (rwxr-xr-x) 또는 775 (rwxrwxr-x)
      • 개인 디렉토리: 700 (rwx------)
      • 공유 디렉토리 (그룹 내): 770 (rwxrwx---) 또는 775 (rwxrwxr-x)

재귀적 변경: -R 옵션을 사용하면 디렉토리와 그 안의 모든 하위 파일/디렉토리 권한을 한 번에 변경할 수 있습니다. (매우 주의해서 사용해야 합니다!)

# my_project 디렉토리와 그 안의 모든 내용에 대해 그룹 쓰기 권한 제거
chmod -R g-w my_project/

5단계: 소유권 변경하기 (chown, chgrp)

  • chown (change owner): 파일/디렉토리의 소유자(user)와 소유 그룹(group)을 변경합니다.

    • sudo chown 새로운소유자 파일/디렉토리 (소유자만 변경)
    • sudo chown :새로운그룹 파일/디렉토리 (그룹만 변경)
    • sudo chown 새로운소유자:새로운그룹 파일/디렉토리 (소유자와 그룹 동시 변경)
    • 참고: 일반적으로 다른 사용자의 파일 소유권을 변경하려면 root 권한(sudo)이 필요합니다.
  • chgrp (change group): 파일/디렉토리의 소유 그룹만 변경합니다.

    • sudo chgrp 새로운그룹 파일/디렉토리

예제:

# my_file.txt의 소유자를 'alice'로 변경
sudo chown alice my_file.txt

# project_dir 디렉토리의 소유 그룹을 'developers'로 변경
sudo chgrp developers project_dir

# report.pdf 파일의 소유자를 'bob', 소유 그룹을 'managers'로 변경
sudo chown bob:managers report.pdf

# data 디렉토리와 그 안의 모든 내용의 소유자를 'www-data', 그룹도 'www-data'로 변경 (웹서버에서 흔히 사용)
sudo chown -R www-data:www-data /var/www/html/data

6단계: 흔한 권한 관련 오류 및 해결 방법

  1. 오류 메시지: Permission denied

    • 원인: 현재 사용자가 해당 파일/디렉토리에 대해 요청한 작업(읽기, 쓰기, 실행/진입)을 수행할 권한이 없습니다.

    • 해결:

      1. ls -l [파일/디렉토리] 로 권한과 소유권 확인.
      2. whoami 명령어로 현재 사용자 확인.
      3. groups 명령어로 현재 사용자가 속한 그룹 확인.
      4. 현재 사용자가 소유자인지, 그룹에 속하는지, 아니면 '다른 사용자'인지 판단.
      5. 필요한 권한(r, w, x)이 해당 대상(u, g, o)에게 부여되어 있는지 확인.
      6. 권한이 없다면, chmod를 사용하여 적절한 권한을 부여합니다. (본인이 소유자이거나 sudo 권한 필요)
      7. 만약 소유권 자체가 잘못되었다면 chown 또는 chgrp를 사용하여 소유권을 변경합니다. (sudo 필요)
    • 예시: 스크립트 실행 시 Permission denied

      $ ./my_script.sh
      bash: ./my_script.sh: Permission denied
      $ ls -l my_script.sh
      -rw-r--r-- 1 user user 100 Jan 15 11:00 my_script.sh  # 실행(x) 권한이 없음
      $ chmod u+x my_script.sh                            # 소유자에게 실행 권한 부여
      $ ./my_script.sh                                    # 이제 실행 가능
    • 예시: 디렉토리 진입 시 Permission denied

      $ cd private_dir/
      bash: cd: private_dir/: Permission denied
      $ ls -ld private_dir/  # 디렉토리 자체의 권한 확인 시 -d 옵션 사용!
      drw------- 1 user user 4096 Jan 15 11:05 private_dir/ # 실행(x) 권한이 없음
      $ chmod u+x private_dir/                             # 소유자에게 실행 권한 부여
      $ cd private_dir/                                    # 이제 진입 가능
  2. 오류 메시지: 파일을 수정/저장할 수 없음 (편집기 등에서)

    • 원인: 해당 파일에 대한 쓰기(w) 권한이 없습니다. 또는 파일이 있는 디렉토리에 대한 쓰기(w) 권한이 없습니다 (파일 삭제/생성 시).
    • 해결:
      1. ls -l [파일] 로 파일 권한 확인. 현재 사용자에게 w 권한이 있는지 확인.
      2. ls -ld [디렉토리] 로 파일이 속한 디렉토리 권한 확인. 파일 생성/삭제 시 현재 사용자에게 w 권한이 있는지 확인.
      3. chmod를 사용하여 필요한 쓰기 권한을 부여합니다.
      4. 주의: 시스템 설정 파일 등 중요한 파일은 일반 사용자가 수정할 수 없도록 root 소유에 쓰기 권한이 제한된 경우가 많습니다. 이 경우 sudo를 사용하여 편집기(예: sudo nano /etc/hosts)를 실행해야 합니다.
  3. 오류 메시지: sudo 사용 시 command not found (오류는 아니지만 혼동 가능)

    • 원인: sudo는 권한 상승 명령어이지, 명령어 자체를 찾는 경로와는 다릅니다. 실행하려는 명령어가 시스템에 설치되지 않았거나, 환경 변수 PATH에 해당 명령어 경로가 포함되지 않은 경우 발생합니다.
    • 해결: 해당 명령어가 실제로 설치되어 있는지 확인하고, 필요하면 설치합니다 (apt search [명령어], sudo apt install [패키지명]).

7단계: 추가 팁 및 고려사항

  • 최소 권한 원칙: 보안을 위해 필요한 최소한의 권한만 부여하는 것이 좋습니다. 모든 사용자에게 777(rwxrwxrwx) 권한을 주는 것은 매우 위험합니다.
  • sudo의 신중한 사용: sudo는 강력한 권한을 제공하므로, 꼭 필요할 때만 사용하고 어떤 명령을 실행하는지 명확히 인지해야 합니다.
  • 특수 권한 (SetUID, SetGID, Sticky Bit): 기본 rwx 외에 특수한 목적의 권한 비트도 있습니다 (ls -l 출력 시 st로 표시됨). 고급 주제이므로 지금 당장 깊게 알 필요는 없지만, 이런 것이 있다는 것만 알아두세요. (예: /tmp 디렉토리의 Sticky Bit t)
  • 연습: 가상 머신이나 안전한 환경에서 직접 파일을 만들고 chmod, chown, chgrp 명령어를 사용해보는 것이 가장 좋은 학습 방법입니다.

사용자 및 그룹 ID(UID/GID)를 1000:1000으로 직접 지정하는 경우는 특정 상황에서 매우 유용합니다.

결론부터 말씀드리면, 1000:1000은 많은 리눅스 배포판(특히 우분투, 데비안 계열)에서 시스템 설치 후 생성되는 첫 번째 일반 사용자에게 기본적으로 할당되는 UID와 GID이기 때문입니다.

이제 어떤 경우에 이것이 중요하고 왜 사용되는지 살펴보겠습니다.

1. 컨테이너 및 가상화 환경 (가장 흔한 경우):

  • 상황: Docker 컨테이너나 가상 머신(VM)을 사용하는데, 호스트(Host) 시스템의 특정 디렉토리를 컨테이너/VM 내부와 공유(볼륨 마운트)해야 할 때가 많습니다.
  • 문제: 호스트 시스템에서 이 디렉토리 안의 파일들은 대부분 호스트의 첫 번째 사용자 (UID 1000, GID 1000)가 소유하고 있을 가능성이 높습니다. 그런데 컨테이너/VM 내부에서 실행되는 프로세스의 사용자가 다른 UID/GID (예: root(0) 또는 컨테이너 내에서 새로 생성된 사용자)를 가지고 있다면, 공유된 디렉토리의 파일에 접근할 때 권한 문제(Permission denied)가 발생할 수 있습니다. 호스트의 UID 1000 사용자가 만든 파일을 컨테이너의 UID 999 사용자가 수정하려고 하면 기본적으로 권한이 없기 때문입니다.
  • 해결 (1000:1000 사용):
    • 컨테이너를 실행할 때, 컨테이너 내부에서 프로세스를 실행할 사용자의 UID와 GID를 호스트의 사용자 ID인 1000:1000으로 명시적으로 지정합니다. 이렇게 하면 컨테이너 내부의 프로세스가 호스트에 마운트된 볼륨의 파일들을 마치 호스트의 첫 번째 사용자인 것처럼 접근하고 수정할 수 있게 됩니다.
    • Docker 예시: docker run -u 1000:1000 -v /host/path:/container/path my_image
    • 또는 Dockerfile 내에서 사용자를 생성할 때 UID/GID를 1000으로 지정할 수도 있습니다.
  • 왜 중요한가: 개발 환경 등에서 호스트의 소스 코드를 컨테이너 내부에서 빌드하거나 실행해야 할 때, 파일 소유권 불일치로 인한 권한 문제를 피하기 위해 매우 흔하게 사용되는 방식입니다.

2. 파일 시스템 마운트 및 공유:

  • 상황: NFS(Network File System)나 Samba 등을 통해 다른 리눅스 시스템과 파일 시스템을 공유할 때.
  • 문제: 각 시스템마다 사용자 이름은 같더라도 내부적인 UID/GID가 다를 수 있습니다. 시스템 A의 john 사용자가 UID 1000이고 시스템 B의 john 사용자가 UID 1001이라면, 시스템 A에서 john이 생성한 파일을 시스템 B의 john이 접근하려고 할 때 권한 문제가 생길 수 있습니다 (시스템 B 입장에서는 UID 1000 사용자가 소유한 파일로 보이기 때문).
  • 해결 (1000:1000 고려):
    • 문제를 진단할 때, 특정 파일의 소유권이 1000:1000으로 표시된다면 "아, 이것은 아마도 공유를 시작한 원본 시스템의 첫 번째 사용자가 만든 파일이겠구나"라고 추측할 수 있습니다.
    • 파일 접근 권한을 설정할 때, 양쪽 시스템에서 UID/GID 매핑을 신경 쓰거나, 공유되는 파일들의 소유권을 특정 UID/GID (때로는 일관성을 위해 1000:1000)로 맞추는 전략을 고려할 수 있습니다. (하지만 이는 사용자 관리 정책에 따라 신중히 결정해야 합니다.)

3. 데이터 마이그레이션 및 백업 복구:

  • 상황: 한 리눅스 시스템에서 다른 리눅스 시스템으로 사용자 홈 디렉토리 등을 통째로 복사하거나, 백업을 복원할 때.
  • 문제: 원본 시스템의 첫 번째 사용자(1000:1000)가 만든 파일들을 새 시스템으로 옮겼는데, 새 시스템의 해당 사용자 UID/GID가 다르거나, 혹은 UID 1000이 아예 존재하지 않는 경우.
  • 해결 (1000:1000 인지):
    • 복사/복원 후 파일 소유권이 여전히 1000:1000으로 남아 있다면, 이 파일들이 원래 어떤 사용자의 것이었는지 추적하는 단서가 됩니다.
    • 이후 chown 명령어를 사용하여 새 시스템의 올바른 사용자에게 소유권을 이전(sudo chown -R newuser:newgroup /path/to/files)해주어야 합니다. 이때 1000:1000으로 표시된 파일들을 대상으로 작업하게 됩니다.

주의사항:

  • 모든 시스템이 1000부터 시작하는 것은 아닙니다. 일부 오래된 시스템이나 특정 배포판에서는 500부터 시작하기도 합니다. 하지만 현대의 주류 데스크탑/서버 배포판에서는 1000이 일반적입니다. cat /etc/login.defs 파일에서 UID_MIN, GID_MIN 값을 확인해볼 수 있습니다.
  • 1000:1000은 관례일 뿐, 절대적인 규칙은 아닙니다. 시스템 관리자가 사용자 UID 범위를 다르게 설정했을 수도 있습니다.
  • 가장 좋은 방법은 UID/GID 숫자보다는 사용자 이름과 그룹 이름을 사용하는 것입니다. (chown myuser:mygroup ...) 숫자 ID를 직접 사용하는 것은 주로 위에서 설명한 시스템 간 상호작용이나 컨테이너 환경처럼 사용자 이름 매핑이 불확실하거나 불가능한 특정 상황에 유용합니다.

요약:

1000:1000으로 UID/GID를 설정하거나, 파일 소유권이 이렇게 표시되는 것을 보는 주된 이유는 리눅스 시스템의 첫 번째 일반 사용자를 지칭하는 경우가 많기 때문입니다. 특히 컨테이너/VM 환경에서 호스트와 파일 시스템을 공유할 때 권한 문제를 해결하기 위해 명시적으로 사용되거나, 시스템 간 데이터 이동/공유 시 원래 소유자를 파악하는 단서로 활용됩니다.