RHEL 기초 #5 사용자/그룹/권한 — UID/GID, sudo, ACL

#4의 systemd unit에 User=nobody 같은 한 줄을 적었습니다. 그 사용자가 시스템에 어떻게 존재하고, 어떤 파일에 접근할 수 있는지가 이번 글의 주제입니다. 운영 이슈의 절반은 권한 문제고, 권한 사고의 절반은 너무 넓은 권한에서 옵니다.

RHEL 기초 시리즈에서 이번 글의 위치:

• #1 RHEL이란 — Fedora에서 RHEL까지, 그리고 AlmaLinux와 Rocky Linux
• #2 셋업 — RHEL 9 설치, Subscription Manager, 첫 로그인
• #3 dnf와 패키지 관리 — repo, modules, AppStream
• #4 systemd 입문 — 서비스, target, journalctl
• #5 사용자/그룹/권한 — UID/GID, sudo, ACL ← 이번 글
• #6 파일 시스템 기본 — XFS, mount, /etc/fstab
• #7 기본 보안 — firewalld, SSH 하드닝

사용자가 어디에 사는가 — /etc/passwd / /etc/shadow #

리눅스의 사용자는 두 파일에 나누어 적혀 있습니다.

/etc/passwd #

$ grep curtis /etc/passwd
curtis:x:1000:1000:Curtis Kim:/home/curtis:/bin/bash

콜론으로 7개 필드:

이 파일은 모든 사용자가 읽을 수 있습니다 (사용자 → UID 매핑이 시스템 곳곳에서 쓰여요).

/etc/shadow #

$ sudo grep curtis /etc/shadow
curtis:$6$abc...$xyz...:19457:0:99999:7:::

비밀번호 해시와 만료 정책이 들어 있는 파일. 600 (root only) 권한이라 일반 사용자에겐 안 보입니다.

UID의 의미 #

   0          → root
   1 ~ 999    → system 사용자 (서비스가 자기 사용자로 떠야 할 때)
   1000~      → 일반 사용자

useradd가 다음 비어 있는 일반 UID를 자동으로 할당합니다. 보통 1000부터 시작합니다.

시스템 사용자가 따로 있는 이유 — nginx, postgres, mysql 같은 데몬이 root로 떠 있으면 한 번 뚫리면 시스템 전체가 위험. 그래서 패키지 설치 시 자동으로 nginx, postgres 같은 시스템 사용자를 만들고, 데몬은 그 사용자로 띄워요. RHEL의 nginx 패키지를 깔면 id nginx로 UID를 확인할 수 있습니다.

그룹 — /etc/group #

$ grep curtis /etc/group
wheel:x:10:curtis
curtis:x:1000:

• curtis:x:1000: — curtis 사용자의 기본 그룹 (UID와 같은 GID로 자동 생성. RHEL의 user private group 패턴)
• wheel:x:10:curtis — curtis가 추가로 들어 있는 그룹. wheel은 sudo 권한을 받는 그룹

$ id
uid=1000(curtis) gid=1000(curtis) groups=1000(curtis),10(wheel)

$ groups
curtis wheel

기본 그룹은 한 개, 추가 그룹은 여러 개 들어갈 수 있습니다.

useradd / usermod / userdel #

$ sudo useradd -m -s /bin/bash -G wheel alice
$ sudo passwd alice

useradd의 자주 쓰는 옵션:

$ sudo usermod -aG wheel alice          # wheel 그룹에 추가 (-a 안 붙이면 기존 그룹 다 덮음!)
$ sudo usermod -s /bin/zsh alice        # 셸 변경
$ sudo usermod -L alice                 # 잠금 (비밀번호 비활성)
$ sudo usermod -U alice                 # 잠금 해제

함정 — -G만 쓰면 기존 추가 그룹을 모두 덮어씁니다. 항상 -aG (--append --groups) 로 쓰세요. 이거 한 번 잘못 치면 사용자가 갑자기 sudo 못 하게 되는 사고가 납니다.

$ sudo userdel alice                    # 사용자만 삭제 (홈 디렉터리는 남음)
$ sudo userdel -r alice                 # 홈 디렉터리와 메일 스풀까지 삭제

운영 머신에서 userdel -r은 신중히 — 홈에 중요한 파일이 있을 수 있습니다. 보통은 usermod -L로 잠그는 정도로 충분.

비밀번호 정책 #

$ sudo chage -l curtis
Last password change                         : Apr 12, 2026
Password expires                             : never
Password inactive                            : never
Account expires                              : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999

$ sudo chage -M 90 -m 7 -W 14 curtis    # 90일 만료, 7일 안엔 변경 못함, 14일 전 경고

파일 권한 — rwx의 의미 #

리눅스 파일 / 디렉터리에는 세 사용자 영역(소유자 / 그룹 / 그 외)마다 세 권한(r/w/x)이 있습니다.

$ ls -l
-rw-r--r--. 1 curtis curtis  256 Apr 13 10:00 notes.txt
drwxr-xr-x. 2 curtis curtis    6 Apr 13 09:55 docs

   - rw- r-- r-- .
   │ │   │   │   └── SELinux context 표시 (.) — [#7]에서 잠깐
   │ │   │   └────── 그 외(other): r-- (읽기만)
   │ │   └────────── 그룹(group):  r-- (읽기만)
   │ └────────────── 소유자(user): rw- (읽기,쓰기)
   └──────────────── 종류: - 일반파일 / d 디렉터리 / l 심볼릭 / b 블록 / c 캐릭터

r / w / x의 의미는 파일과 디렉터리에서 다릅니다 #

디렉터리의 x가 직관과 어긋나는 부분입니다. 디렉터리에 x가 없으면 그 안의 파일을 어떤 권한으로도 못 봅니다. “파일 권한은 다 열려 있는데 왜 안 읽히지?” 하면 99% 가 이거.

chmod — 두 표기법 #

8진수 (numeric) 표기 #

각 권한을 비트로:

r = 4, w = 2, x = 1
rwx = 7   r-x = 5   r-- = 4   --- = 0

세 영역(소유자/그룹/그 외)을 한 비트씩:

$ chmod 644 file.txt          # rw-r--r--   일반 파일 기본
$ chmod 600 secret.key        # rw-------   비공개 파일 (SSH 키 등)
$ chmod 755 script.sh         # rwxr-xr-x   실행 가능한 스크립트
$ chmod 700 ~/.ssh            # rwx------   SSH 디렉터리
$ chmod 750 dir               # rwxr-x---   소유자 + 그룹 접근, 외부 차단

운영에서 가장 자주 만나는 4-5 패턴이라 손에 익혀두면 좋습니다.

심볼릭 (symbolic) 표기 #

$ chmod u+x script.sh         # 소유자에게 x 추가
$ chmod g-w file              # 그룹의 w 제거
$ chmod o= file               # 그 외 권한 모두 제거
$ chmod a+r file              # all (모두) 에게 r 추가
$ chmod u=rw,g=r,o= file      # 절대 지정 (= 으로)

조금 더 인간 친화적이라 한 권한만 뺐다 더할 때 자주 씁니다.

chown / chgrp — 소유자 바꾸기 #

$ sudo chown alice file              # 소유자만
$ sudo chown alice:devs file         # 소유자와 그룹 동시
$ sudo chgrp devs file               # 그룹만
$ sudo chown -R alice:devs /var/app  # 디렉터리 전체 재귀

-R은 운영에서 자주 쓰지만 위험한 옵션입니다. 한 번 잘못 치면 시스템 디렉터리의 소유자가 통째로 바뀌어 부팅 불가가 될 수 있습니다. 경로를 두 번 확인하고 누르세요.

특수 비트 — SUID / SGID / Sticky #

rwx 만으론 부족한 경우가 있어 비트 세 개가 더 있습니다.

$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root ... /usr/bin/passwd       # rws — SUID 박힘

$ ls -ld /tmp
drwxrwxrwt. ... /tmp                               # rwt — sticky 박힘

$ chmod 4755 myprog          # SUID + 755
$ chmod g+s shared-dir       # 디렉터리에 SGID
$ chmod +t /shared           # sticky

운영에서 직접 SUID를 부여하는 일은 드물고, 이미 부여된 SUID 바이너리 목록을 정기 점검 하는 게 보안 관리의 기본입니다 (find / -perm -4000 같은 명령으로).

umask — 새 파일의 기본 권한 #

새로 만든 파일의 권한이 보통 644, 디렉터리가 755 인 이유는 umask 때문입니다.

$ umask
0022

umask는 “기본 최대 권한에서 뺄 비트” 입니다. 파일의 기본 최대는 666, 디렉터리는 777. 거기서 022를 빼면:

파일:     666 - 022 = 644 (rw-r--r--)
디렉터리: 777 - 022 = 755 (rwxr-xr-x)

서버에선 보통 umask 027 또는 077로 더 좁게 — 새 파일이 그 외 사용자에게 안 보이도록. /etc/profile, /etc/bashrc, 또는 사용자 ~/.bashrc에서 설정.

ACL — rwx가 부족할 때 #

표준 rwx는 한 사용자, 한 그룹만 다룹니다. 두 그룹에 다른 권한을 주거나, 특정 한 사용자에게만 추가 권한을 주는 경우에는 부족합니다. 그때 쓰는 게 **ACL(Access Control List)**입니다.

확인 — getfacl #

$ getfacl /var/data
# file: var/data
# owner: root
# group: data
user::rwx
group::r-x
other::---

ACL이 추가 안 된 파일은 보통의 rwx와 같은 정보를 보여줍니다.

설정 — setfacl #

$ sudo setfacl -m u:alice:rwx /var/data
$ getfacl /var/data
# file: var/data
# owner: root
# group: data
user::rwx
user:alice:rwx              ← 새로 추가됨
group::r-x
mask::rwx
other::---

$ sudo setfacl -m g:devs:r-x /var/data

$ sudo setfacl -x u:alice /var/data           # 한 항목만 제거
$ sudo setfacl -b /var/data                   # 모든 ACL 제거

ACL이 박힌 파일은 ls -l에서 권한 끝에 + 표시가 보입니다.

$ ls -l /var/data
drwxrwx---+ 2 root data 6 Apr 13 11:00 /var/data
                    ↑
                    ACL이 추가로 적용되어 있다는 표시

default ACL — 새로 만들어지는 파일에 자동 적용 #

디렉터리의 default ACL은 그 안에 새로 생성되는 파일/디렉터리에 자동으로 적용됩니다.

$ sudo setfacl -d -m u:alice:rwx /var/data    # -d가 default

이 한 줄만 적용해두면 그 안에 만들어지는 모든 파일에 alice 권한이 자동으로 따라갑니다. 공유 디렉터리 운영의 핵심입니다.

sudo — 권한 위임 #

root 비밀번호를 공유하지 않고 특정 사용자에게 특정 명령만 root 권한으로 실행하게 해주는 도구. RHEL 9의 기본 정책은:

%wheel  ALL=(ALL)       ALL

“wheel 그룹은 어떤 호스트에서든 모든 사용자로 모든 명령을 실행할 수 있다.” usermod -aG wheel alice만 하면 alice가 sudo가 됩니다.

/etc/sudoers와 /etc/sudoers.d/ #

/etc/sudoers를 직접 편집하지 마세요. **visudo**를 쓰세요.

$ sudo visudo                              # /etc/sudoers 자체
$ sudo visudo -f /etc/sudoers.d/mycompany  # 분리 파일

visudo는 저장 직전에 문법 검사를 합니다. 문법이 깨진 상태로 저장하면 sudo 자체가 망가져 시스템 복구가 어려워요. 직접 vi /etc/sudoers는 위험.

요즘은 거의 /etc/sudoers.d/ 안에 별도 파일로 분리해 둡니다. 패키지 / 역할별로 한 파일씩.

한정적 sudo #

운영에서는 “이 사용자는 이 명령만” 처럼 좁힙니다.

deploy  ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

• NOPASSWD: — 이 명령엔 비밀번호 없이 (자동화용)
• 명령 두 개만 나열 — 그 외 명령은 sudo 권한 없음

자동 배포 도구가 머신에 SSH로 붙어 sudo systemctl restart myapp만 치면 되는 패턴. 다른 곳에 권한이 새는 걸 막습니다.

자주 쓰는 sudo 명령 #

$ sudo whoami                   # → root (가장 빠른 sudo 동작 확인)
$ sudo -i                       # root 셸로 진입 (`sudo su -` 와 비슷)
$ sudo -u alice cmd             # alice 사용자로 cmd 실행
$ sudo -l                       # 내가 쓸 수 있는 sudo 명령 목록
$ sudo -k                       # 인증 캐시 즉시 만료 (다음 sudo 때 비밀번호 다시)

wheel vs sudo 그룹 — 일부 다른 배포판 (우분투 등) 은 sudo 그룹을 씁니다. RHEL은 전통적으로 wheel. 두 그룹 다 같은 역할이지만 이름이 달라요. 우분투에서 온 분이 sudo 그룹을 만들면 RHEL 에선 동작 안 합니다 — wheel로.

자주 쓰는 명령 한 표 #

자주 만나는 함정 #

“-aG 빼먹고 그룹 갈아치움” #

$ sudo usermod -G devs curtis   # ← curtis 가 wheel 그룹에서 빠져 sudo 못 함!

무조건 -aG (append). 걸렸으면 root로 돌아가 다시 usermod -aG wheel curtis.

“디렉터리 권한이 닫혀 있는데 안의 파일이 다 풀려 있음” #

권한 구조에서 디렉터리가 더 우선. 상위 디렉터리에 x가 없으면 안의 파일은 어떻게 풀어둬도 접근 불가입니다. 보안 점검 시 디렉터리 권한부터 봅니다.

“chmod 777로 일단 풀고 잊어버림” #

장애 디버깅 중 chmod -R 777 /var/app으로 일단 풀고 동작 확인하는 패턴 — 나중에 안 돌려놓으면 SELinux/감사 정책에 잡혀 더 큰 사고. 풀었으면 반드시 돌려놓고, 운영은 처음부터 정확한 권한으로.

“ssh 키 권한이 너무 풀려서 거부됨” #

~/.ssh             700
~/.ssh/authorized_keys   600
~/.ssh/id_rsa            600

이 권한이 더 풀려 있으면 SSH가 키 인증을 거부합니다. 우분투에서 RHEL로 옮겨오며 가장 자주 만나는 증상.

“ACL 박았는데 SELinux가 막음” #

ACL까지 통과해도 RHEL의 SELinux가 한 층 더 검사합니다. ACL은 OK인데 접근 거부 (Permission denied)면 SELinux 라벨 문제일 가능성이 높습니다. 중급 #1 SELinux에서 다룹니다.

정리 #

이번 글에서 잡은 그림:

• 사용자는 **/etc/passwd (공개) + /etc/shadow (비공개)**에 산다. UID 1000+ 가 일반 사용자
• **useradd -m -s /bin/bash -G wheel <u>**가 가장 자주 만나는 새 사용자 생성 패턴. wheel이 sudo 그룹
• usermod -G가 아닌 -aG — 한 번 잘못 치면 sudo 권한이 통째로 사라짐
• 권한 비트 rwx — **디렉터리의 x는 진입(=접근)**의 의미라는 점이 함정
• chmod의 8진수와 심볼릭 두 표기법, chown/chgrp의 -R은 신중히
• 표준 권한이 부족할 땐 ACL — setfacl -m u:alice:rwx, default ACL로 새 파일 자동 적용
• sudo는 **/etc/sudoers.d/**에 분리, visudo 로만 편집
• RHEL의 sudo 그룹은 wheel (우분투의 sudo 그룹과 다름)

다음 — 파일 시스템 #

권한이 적용되는 무대인 파일시스템 자체가 다음 글의 주제입니다. 디스크가 어떻게 마운트되어 트리 안에 들어가고, 새 디스크를 추가할 때 무엇을 적어야 하는지.

#6 파일 시스템 기본 — XFS, mount, /etc/fstab에서는 RHEL 9의 기본 파일시스템 XFS의 모양 (ext4와의 차이), lsblk / df / du로 디스크 보기, 새 디스크를 추가해 파티셔닝하고 mkfs.xfs로 포맷해 마운트까지의 한 사이클, **/etc/fstab**에 영구 등록(UUID로 안전하게), 그리고 swap 운영까지 잡습니다.