12. ls -l 출력 해석하기

파일 · 권한 · 사용자 관리 12 / 50 · Part 2. Linux 파일 종류와 속성
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정 analyst)
기초편 연계: 「리눅스 시스템 기초」 13. Linux 파일 종류 · 15. Linux 파일 권한 이해

1. 들어가며

ls -l은 Linux 관리자와 보안 분석가가 매일 보는 출력이다. 이 한 줄에는 inode의 핵심 정보 대부분 이 압축되어 있다.

이번 글에서는 ls -l 한 줄을 칸 단위로 해석한다. 특히 점검에서 놓치기 쉬운 표시 — s/S, t/T, 권한 뒤의 +와 ., 숫자로만 보이는 소유자 — 를 Rocky Linux 9.8과 Ubuntu 24.04 실제 출력으로 확인한다.

---

2. 핵심 개념

2-1. 칸별 의미

순서	예	의미	출처
1	-	파일 종류 (11편)	inode mode 상위 비트
2	rw-r-----	권한 9비트 (21편)	inode mode 하위 비트
3	+ 또는 .	ACL / SELinux 표시 (없으면 공백)	확장 속성(xattr)
4	1	링크 수	inode
5	analyst	소유자 (UID를 이름으로 변환)	inode uid
6	analyst	그룹 (GID를 이름으로 변환)	inode gid
7	3	크기(바이트). 장치 파일은 major, minor	inode size / rdev
8	Dec 1 2025	mtime	inode mtime
9	report.txt	이름	디렉터리 엔트리

2-2. 날짜 표시 규칙

GNU ls는 최근 6개월 이내 파일은 Sep 24 10:35처럼 시각을, 그보다 오래되었거나 미래 시각인 파일은 Dec 1 2025처럼 연도를 표시한다. 분석 기록에는 형식이 섞이지 않도록 --time-style=long-iso 또는 full-iso를 사용한다.

2-3. 권한 칸의 특수 표시

표시	의미
user x 자리의 s / S	SUID 설정 (실행 권한 있음 / 없음) — 28편
group x 자리의 s / S	SGID 설정 (실행 권한 있음 / 없음) — 29편
other x 자리의 t / T	Sticky Bit (실행 권한 있음 / 없음) — 30편
권한 뒤 +	ACL 존재 → 보이는 9비트가 전부가 아님 — 44편
권한 뒤 .	SELinux 보안 컨텍스트 존재 (RHEL 계열)

---

3. 동작 원리

ls -l은 파일마다 statx()(또는 lstat())로 inode 정보를 읽고 사람이 읽을 수 있게 변환한다.

• UID/GID → 이름 변환: inode에는 숫자만 저장된다. ls가 NSS(/etc/passwd, /etc/group, LDAP 등)에서 이름을 찾아 바꿔 보여 준다. 해당 번호의 계정이 없으면 숫자 그대로 표시된다.
• 권한 문자열 생성: mode 12비트(특수 3 + 기본 9)를 rwxsStT- 문자로 변환한다.
• + 표시: 파일에 POSIX ACL 확장 속성이 있으면 붙는다.
• . 표시: SELinux 컨텍스트가 있으면 붙는다. SELinux가 활성화된 Rocky 서버에서는 대부분 파일에 .이 보이고, Ubuntu(AppArmor 사용)에서는 보통 보이지 않는다. 이 실습 컨테이너는 SELinux 컨텍스트가 없어 Rocky에서도 .이 나타나지 않았다.

---

4. 명령어 실습

/srv/lab12는 root가 미리 만든 실습 디렉터리다. report.txt(analyst 소유, 640), 실습용 SUID 파일 backup-tool, 공유 디렉터리 share(1777), ACL이 설정된 acl.txt로 구성했다.

# 1) 실습 디렉터리 전체
ls -l /srv/lab12

# 2) 디렉터리 자체 (Sticky Bit 표시 비교)
ls -ld /srv/lab12/share /etc

# 3) 시스템의 SUID 파일과 문자 장치
ls -l /usr/bin/passwd /dev/null

# 4) 이름 대신 숫자로 / 날짜 형식 고정
ls -ln /srv/lab12/report.txt
ls -l --time-style=long-iso /srv/lab12/report.txt

---

5. 실행 결과

Rocky Linux 9.8

Ubuntu 24.04.5

텍스트 원본(실제 출력) — Rocky:

[analyst@rocky9-lab ~]$ ls -l /srv/lab12
total 36
-rw-r--r--+ 1 root    root        0 Sep 24 10:35 acl.txt
-rwsr-xr-x  1 root    root    27936 Sep 24 10:35 backup-tool
-rw-r-----  1 analyst analyst     3 Dec  1  2025 report.txt
drwxrwxrwt  2 root    root     4096 Sep 24 10:35 share
[analyst@rocky9-lab ~]$ ls -ld /srv/lab12/share /etc
drwxr-xr-x 1 root root 4096 Sep 24 10:35 /etc
drwxrwxrwt 2 root root 4096 Sep 24 10:35 /srv/lab12/share
[analyst@rocky9-lab ~]$ ls -l /usr/bin/passwd /dev/null
crw-rw-rw- 1 root root  1, 3 Sep 24 10:35 /dev/null
-rwsr-xr-x 1 root root 32656 May 15  2022 /usr/bin/passwd
[analyst@rocky9-lab ~]$ ls -ln /srv/lab12/report.txt
-rw-r----- 1 1000 1000 3 Dec  1  2025 /srv/lab12/report.txt
[analyst@rocky9-lab ~]$ ls -l --time-style=long-iso /srv/lab12/report.txt
-rw-r----- 1 analyst analyst 3 2025-12-01 09:30 /srv/lab12/report.txt

---

6. 결과 해석

출력	해석
-rw-r--r--+ ... acl.txt	기본 권한은 644지만 +가 있어 ACL로 추가 권한이 부여됨. getfacl로 확인해야 실제 접근 범위를 알 수 있다
-rwsr-xr-x ... backup-tool	user x 자리의 s = SUID. 실행하면 소유자(root) 권한으로 동작
-rw-r----- ... Dec 1 2025 report.txt	6개월 이상 지난 파일이라 연도로 표시
drwxrwxrwt ... share	other x 자리의 t = Sticky Bit
drwxr-xr-x ... /etc 링크 수 1	컨테이너 overlay FS는 디렉터리 링크 수를 1로 보고한다. ext4·xfs의 "2 + 하위 디렉터리" 규칙이 모든 FS에 적용되지는 않는다
crw-rw-rw- ... 1, 3 /dev/null	크기 자리에 major, minor
-rwsr-xr-x ... /usr/bin/passwd	대표적인 정상 SUID 파일 (본인 비밀번호 변경 시 /etc/shadow 수정 필요)
ls -ln → 1000 1000	inode에 실제 저장된 값은 UID/GID 숫자
--time-style=long-iso → 2025-12-01 09:30	연도·시각이 모두 보이는 고정 형식
total 36	목록에 나온 항목들이 차지하는 블록 합계(1KiB 단위)

Rocky와 Ubuntu의 /usr/bin/passwd 크기가 다른 것(32656 vs 64152)도 눈여겨볼 만하다. 같은 이름의 시스템 파일도 배포판·버전마다 해시가 다르다. 해시 기반 무결성 기준값은 배포판·버전별로 따로 관리해야 한다 (20편).

---

7. 보안 관점

발견	의미	다음 확인
예상 밖 위치의 s	비표준 SUID 파일 → 권한 상승 경로 가능성	패키지 소유 여부, 해시 (47편)
S (대문자)	SUID는 있으나 실행 권한 없음 → 설정 실수 또는 흔적	누가 언제 설정했는지 (ctime)
+	9비트만 보고 "안전"하다고 판단하면 오판	getfacl
소유자가 숫자	삭제된 계정의 잔여 파일 → 같은 UID로 새 계정이 생기면 소유권을 그대로 물려받음	find / -nouser -o -nogroup (37편)
웹 루트 파일 소유자가 웹 서버 계정	웹 프로세스가 파일을 수정할 수 있음	업로드 디렉터리 외 쓰기 권한 제거

주의: s가 보인다고 곧 취약점은 아니다. passwd, sudo, su처럼 SUID가 있어야 동작하는 정상 프로그램 이 있다. 판단 기준은 기준값(Baseline)과의 차이다.

---

8. 보안관제 관점

관점	적용
Evidence	보고서에는 ls -l 캡처보다 ls -ln --time-style=full-iso 또는 stat 결과를 남긴다. 이름 변환·날짜 표시 차이로 인한 해석 오류를 막는다
Detection	+, s, t 변화는 FIM이 권한 변경으로 탐지한다. auditd에서는 chmod, setxattr 계열 시스템 콜이 대응된다
Investigation	숫자 소유자 파일은 "과거 계정이 무엇을 남겼는가"를 보여 준다. 퇴사자·삭제 계정 조사 시 유용
Baseline	배포판·버전별로 SUID 목록과 해시를 따로 저장한다

[Detection]  FIM: /usr/local/bin/backup-tool 권한 0755 → 4755
     ↓
[Evidence]   ls -ln --time-style=full-iso → -rwsr-xr-x 0 0 ... (ctime = 변경 시각)
     ↓
[판단]       패키지 소유 아님 + 신규 SUID → 비인가 변경 가능성
     ↓
[Investigation] 같은 시각의 sudo·su 로그로 변경 주체 확인 (49편)
     ↓
[Response]   권한 원복(chmod u-s), 파일 해시 보존, 변경 계정 조사

---

9. 실무에서 자주 발생하는 실수

실수	결과	예방
+를 보지 못하고 9비트만으로 판단	ACL로 열린 접근을 놓침	+ 확인 시 getfacl
날짜 표시 형식 혼동	연도 누락·시각 누락	--time-style=long-iso
링크 수를 파일 개수로 오해	FS마다 규칙이 다름	필요한 경우 find로 직접 세기
소유자 이름만 기록	계정 삭제·재생성 후 혼동	ls -n으로 UID 기록
크기 4096 디렉터리를 "4KB 데이터"로 해석	용량 분석 오류	du -sh 사용

---

10. 실습 체크리스트

[ ] ls -l 의 9개 칸을 순서대로 설명할 수 있다
[ ] s / S / t / T 표시의 차이를 구분했다
[ ] 권한 뒤 + 표시가 ACL 을 의미함을 확인했다
[ ] ls -n 으로 UID/GID 숫자를 확인했다
[ ] --time-style=long-iso 로 날짜 형식을 고정했다
[ ] Rocky 와 Ubuntu 의 같은 파일 크기가 다를 수 있음을 확인했다

---

11. 핵심 정리

• ls -l 한 줄은 종류·권한·ACL/SELinux 표시·링크 수·소유자·그룹·크기·mtime·이름으로 구성된다.
• 이름을 제외한 모든 값은 inode에서 오고, 소유자는 숫자로 저장 된다.
• s/S는 SUID·SGID, t/T는 Sticky Bit, +는 ACL, .은 SELinux 컨텍스트다.
• 6개월이 넘은 파일은 시각 대신 연도가 표시된다. 분석에는 고정 날짜 형식을 쓴다.
• 디렉터리 링크 수 규칙은 파일 시스템마다 다를 수 있다.
• 특수 표시는 "취약점"이 아니라 "확인할 대상"이다. 기준값과 비교해 판단한다.

---

12. 다음 편 예고

다음 글 「13. inode 이해하기」 에서는 debugfs로 ext4 inode를 직접 열어 보고, 디스크 용량이 남아 있는데도 파일을 만들 수 없는 inode 고갈 을 실제로 재현한다.

---

참고 자료

• ls(1) — https://man7.org/linux/man-pages/man1/ls.1.html
• GNU Coreutils: What information is listed — https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html
• acl(5) — https://man7.org/linux/man-pages/man5/acl.5.html

---

시리즈 이동

• [이전 글] 11. Linux 파일 종류 7가지
• [현재 글] 12. ls -l 출력 해석하기
• [다음 글] 13. inode 이해하기