LabHub

RHEL 계열 관리 · rpm 저수준 · 이론

rpm 질의와 검증

LabHub 에서 이어서 보기

한 줄 요약

rpm 은 설치 도구이기 전에 질의 도구다. 그리고 rpm -V 는 시스템에 무슨 일이 있었는지 알려 주는 강력한 감사 도구다.

왜 이게 필요했나

장애나 침해 의심 상황에서는 "패키지가 설치돼 있다"보다 **설치된 파일이 원래
패키지와 같은가**가 중요하다. 파일의 소유 패키지, 설치 스크립트, 설정 파일 목록과
다이제스트 차이를 rpm 데이터베이스에서 바로 조회하면 무작정 재설치하기 전에
변경 범위를 좁힐 수 있다. 단, rpm 데이터베이스까지 신뢰할 수 없는 사고라면
별도의 신뢰 가능한 매니페스트와도 비교해야 한다.

어떻게 동작하나

질의 (-q)

rpm -qa                          # 설치된 전부rpm -qa | wc -lrpm -qi httpd                    # 상세 정보rpm -ql httpd                    # 설치한 파일 목록rpm -qc httpd                    # 설정 파일만rpm -qd httpd                    # 문서 파일만rpm -qf /usr/sbin/httpd          # 이 파일의 주인rpm -q --changelog httpd | headrpm -q --scripts httpd           # 설치 스크립트(%pre/%post 등)rpm -q --requires httpdrpm -q --provides httpd

파일 앞에 -p 를 붙이면 설치되지 않은 .rpm 파일을 조회한다.

rpm -qpi ./labhub-tool-1.0-1.noarch.rpmrpm -qpl ./labhub-tool-1.0-1.noarch.rpmrpm -qp --qf '%{NAME} %{VERSION} %{RELEASE} %{ARCH}\n' ./x.rpm

--qf(queryformat)로 원하는 필드만 뽑는 것이 자동화의 핵심이다. epoch 처리에는 삼항 표기가 필요하다.

rpm -qp --qf '%{NAME}\t%|EPOCH?{%{EPOCH}}:{0}|\t%{VERSION}\t%{RELEASE}\t%{ARCH}\n' ./x.rpm

epoch 가 없는 패키지는 필드가 (none) 으로 나오므로, 이 표기로 0 을 채워 넣는다. 파일 이름에는 epoch 가 들어가지 않으므로 매니페스트에는 반드시 이 값을 적어야 한다.

검증 (-V)

rpm -V httpdrpm -Va | head                   # 전체 검증 (느리다)

출력은 SM5DLUGTP c /etc/httpd/conf/httpd.conf 같은 형식이다.

| 문자 | 뜻 |
| --- | --- |
| S | 파일 크기 다름 |
| M | 모드(권한/타입) 다름 |
| 5 | 파일 내용 다이제스트 다름 (역사적으로 MD5 표시에서 유래) |
| D | 장치 번호 다름 |
| L | 심링크 대상 다름 |
| U / G | 소유자/그룹 다름 |
| T | mtime 다름 |
| P | capabilities 다름 |
| c (두 번째 열) | 설정 파일 표시 |

설정 파일(c)이 바뀐 것은 정상이다. 관리자가 고쳤을 테니까. 하지만 바이너리가 바뀌었다면 조사해야 한다 — 침해 사고이거나 누군가 손으로 덮어썼다는 뜻이다.

서명 검증

rpm --checksig ./x.rpmrpmkeys --checksig ./x.rpm       # 권장 표기rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-...rpmkeys --list

digests signatures OK 가 나와야 정상이다. 키를 등록하지 않은 상태에서는 다이제스트만 통과하고 서명은 확인 불가로 남는데, 그것을 "통과" 로 오독하기 쉽다. 검사 전에 rpmkeys --list 로 키가 등록돼 있는지 확인하는 것이 습관이 되어야 한다.

패키지 만들기

~/rpmbuild/  SPECS/     labhub-tool.spec  SOURCES/   labhub-tool-1.0.tar.gz  BUILD/     (빌드 중간 산출물)  BUILDROOT/ (가상의 설치 루트)  RPMS/      (완성된 바이너리 rpm)  SRPMS/     (소스 rpm)

spec 파일의 뼈대.

Name:      labhub-toolVersion:   1.0Release:   1%{?dist}Summary:   예제 도구License:   MITSource0:   %{name}-%{version}.tar.gzBuildArch: noarchRequires:  coreutils%description...%prep%setup -q%buildmake%installmake install DESTDIR=%{buildroot} PREFIX=/usr%files/usr/bin/labhub-tool%changelog* Sat Aug 15 2026 LabHub <lab@labhub.local> - 1.0-1- 최초 패키징

%files 에 적히지 않은 파일이 buildroot 에 있으면 빌드가 실패한다. "Installed (but unpackaged) files found" 가 그 메시지다. 반대로 %files 에 적었는데 실제로 없어도 실패한다. 이 엄격함이 패키지 내용을 정확하게 유지해 준다.

rpmbuild -ba ~/rpmbuild/SPECS/labhub-tool.spec     # 바이너리 + 소스 rpmrpmbuild -bb ...                                    # 바이너리만rpm2cpio x.rpm | cpio -idmv                         # 설치 없이 내용 풀기

현장에서 만나는 모습

rpm -Va 로 침해 흔적 찾기. 시스템이 이상하면 이 명령으로 변조된 바이너리를 찾는다. 다만 rpm 데이터베이스 자체가 변조됐을 수 있으므로 믿을 수 있는 사본과 비교해야 확실하다.

다음 실습에서 할 것

rpm 으로 질의·검증하고, spec 파일로 직접 패키지를 빌드해 설치까지 한다.