리눅스 id 명령어 사용법 - uid·gid·보조그룹 확인과 권한 오류 진단

이 명령어를 언제 쓰는가

"분명히 그룹에 넣었는데 Permission denied가 난다"는 상황에서 쓴다. 파일 권한은 ls -l로 보이지만, 정작 내가 지금 어떤 uid와 어떤 그룹 집합을 갖고 있는지는 id로만 알 수 있다.

배포 스크립트에서 root 여부를 판별할 때, 도커 컨테이너에 호스트와 같은 uid로 들어갈 때, NFS 마운트에서 소유자가 숫자로만 보일 때도 id부터 친다. 짧지만 권한 문제 진단의 출발점이다.

기본 형식

id [옵션] [사용자명]

인자 없이 실행하면 현재 프로세스의 실제 자격 증명을 보여주고, 사용자명을 주면 /etc/passwd와 /etc/group(또는 LDAP 같은 이름 서비스)을 조회한 결과를 보여준다. 이 둘이 다를 수 있다는 점이 뒤에서 나올 핵심이다.

자주 쓰는 옵션

옵션	의미	예시
(없음)	uid, gid, 보조그룹을 모두 표시	`id`
-u	uid 숫자만	`id -u`
-g	기본 그룹 gid 숫자만	`id -g`
-G	속한 모든 그룹의 gid를 공백 구분으로	`id -G`
-n	숫자 대신 이름으로(-u/-g/-G와 함께)	`id -nG`
-r	유효 ID가 아니라 실제(real) ID	`id -ru`
-Z	SELinux 보안 컨텍스트(RHEL 계열)	`id -Z`

출력 읽는 법

uid=1000(hscho) gid=1000(hscho) groups=1000(hscho),27(sudo),998(docker),1001(deploy)

uid는 파일 소유자 비교에 쓰이는 사용자 번호다. 리눅스에서 관리자는 이름이 root라서가 아니라 uid가 0이라서 관리자다. 관례상 0은 root, 1~999는 시스템 계정, 1000 이상이 일반 계정이다(RHEL 6 이전은 500부터였다).

gid는 기본 그룹이다. 이 사용자가 새로 만드는 파일의 그룹 소유자가 여기서 정해진다.

groups는 기본 그룹과 보조 그룹을 모두 합친 목록이다. 파일 접근 권한을 판정할 때 커널은 이 목록 전체를 본다. 즉 drwxrwx--- root docker 디렉터리에 들어가려면 groups 안에 docker가 있어야 한다.

실전 예제

1) 권한 거부가 났을 때 내 그룹과 파일의 그룹을 나란히 비교한다.

id -nG
ls -ld /var/log/nginx

2) 스크립트에서 root로 실행됐는지 검사한다(이름이 아니라 uid로).

if [ "$(id -u)" -ne 0 ]; then
  echo "root 권한이 필요하다. sudo로 다시 실행하라." >&2
  exit 1
fi

3) 도커 컨테이너를 호스트와 같은 uid로 띄워 볼륨 파일 소유자가 root로 생기는 것을 막는다.

docker run --rm -u "$(id -u):$(id -g)" -v "$PWD":/work -w /work alpine touch out.txt

4) 다른 계정(서비스 계정)의 소속 그룹을 확인한다.

id www-data
id -nG postgres

5) 특정 그룹에 속해 있는지 조건문으로 판정한다.

if id -nG | tr ' ' '\n' | grep -qx docker; then
  echo "docker 그룹 있음"
fi

6) sudo로 승격된 상태에서 원래 누구였는지 본다.

sudo id
echo "$SUDO_USER"

함정과 주의점

usermod -aG 직후에는 적용되지 않는다. 이게 가장 자주 겪는 함정이다. 보조 그룹은 로그인할 때 프로세스에 한 번 박히고 그 후로는 바뀌지 않는다. 그래서 그룹을 추가해도 이미 열려 있는 셸에는 반영되지 않는다. 판별법은 간단하다.

sudo usermod -aG docker hscho
id          # 현재 프로세스의 실제 그룹 → docker 없음
id hscho    # 계정 DB 조회 결과   → docker 있음

이 둘이 다르면 다시 로그인해야 한다는 뜻이다. 재접속이 어려우면 newgrp docker로 새 그룹이 적용된 하위 셸을 띄울 수 있다. GUI 데스크톱이면 로그아웃까지 해야 완전히 반영된다. 실행 중인 데몬은 재시작해야 한다.

uid는 같지만 다른 서버에서는 다른 사람일 수 있다. NFS나 rsync로 파일을 옮기면 이름이 아니라 숫자 uid/gid가 그대로 붙는다. A 서버의 uid 1001이 deploy이고 B 서버의 uid 1001이 jenkins라면 파일 소유자가 조용히 바뀐다. 여러 서버를 다룬다면 useradd -u 1001처럼 uid를 명시해 통일하거나 LDAP 같은 중앙 계정 관리를 쓰는 것이 맞다. NFSv3 환경에서는 보조 그룹이 16개까지만 전달된다는 제약도 있어서, 그룹이 많은 계정은 17번째 그룹 권한이 조용히 무시된다.

uid 0인 계정이 root 하나뿐인지 확인하라. 침해 점검의 기본 항목이다. 아래 명령의 결과가 root 한 줄이 아니면 백도어 계정을 의심해야 한다.

awk -F: '$3 == 0 {print $1}' /etc/passwd