가상 컨테이너(Ubuntu Hardy)에 640MB의 wtmp 파일이 있다는 것을 방금 확인했습니다.
# last -n 10000 -f /var/log/wtmp.1|wc -l
384
# ls -hl /var/log/wtmp.1
-rw-rw-r-- 1 root utmp 641M 21. Sep 07:49 /var/log/wtmp.1
logrotate가 설치되지 않았습니다(방금 이 작업을 수행하고 강제 회전했습니다).
표시되지 않는 레코드가 있습니까 last(마지막 1000개의 레코드가 표시되어야 하지만 분명히 384개만 표시됨).
매뉴얼 페이지를 잠깐 살펴보면 wtmp/utmp단일 항목이 약 1.6MB를 사용해야 하는 것 같지 않습니다.
last이 파일들을 검사하는 것 외에 다른 프로그램이 있나요?
답변1
logrotate좋은 생각이에요.
일반 파일과 마찬가지로, wtmp는 "희소"할 수 있으며(lseek(2) "취약성" 및 참조 ls -s) 실제로 매우 적은 디스크를 차지하는 극단적인 파일 크기를 드러낼 수 있습니다. 만약 구멍이라면, 그 구멍은 어떻게 거기에 이르렀나요? getty(8)친구야, 실수가 있을 수도 있어. 또는 시스템 충돌 및 fsck 복구로 인해 발생할 수 있습니다.
wtmp의 원시 콘텐츠를 보려는 경우 od또는 hd바이너리 파일을 보는 것이 적합하며 긴 드라이 런을 표시하는 즐거운 부작용이 있습니다.
다시는 그런 일이 일어나지 않는 한, 나는 그것에 대해 너무 많이 생각하지 않을 것입니다. 조금 더 유능한 Invader가 더 잘했을 것입니다. 콘텐츠는 그다지 흥미롭지 않고 거의 의존하지 않습니다.
답변2
이 내용이 유용하다고 생각하는 다른 사람들을 돕기 위해...
last이 파일들을 검사하는 것 외에 다른 프로그램이 있나요?
예, 시도해 보세요 utmpdump.
$ utmpdump /var/log/wtmp
답변3
cp --sparsewtmp에 취약점이 있을 수 있다고 의심되는 경우, 충분히 새로운 coreutils가 있거나 fallocate --dig-holes출시되지 않은 util-linux 2.25 버전을 사용하는 경우 이를 사용하여 취약점을 제거할 수 있습니다. 아마도 보다 실용적인 접근 방식은 wtmp를 다시 패키지하는 것입니다.
utmpdump /var/log/wtmp | utmpdump -r > /tmp/newtmp
ls -l /var/log/wtmp /tmp/newtmp # if significantly smaller
chown root:root /tmp/newtmp
chmod 0554 /tmp/newtmp
mv /tmp/newtmp /var/log/wtmp
파일이 꽤 크더라도 회전해서 압축하면 됩니다.
mv /var/log/wtmp{,.1}
gzip -9 /var/log/wtmp.1
답변4
utmp일반적으로 희소 - 해당 레코드는 세션 제어 터미널의 주요 + 부 장치 번호로 색인화됩니다. 이렇게 하면 로그아웃 중에 삭제되지 않은 "오래된" 레코드가 결국 동일한 터미널의 다음 세션에서 덮어쓰여지게 됩니다.
시스템이 부팅될 때마다 안전하게 지워질 수 있지만 /run/utmp대부분의 배포판에는 아직 포함되어 있지 않습니다.
wtmp예아니요일반적으로 이벤트가 발생할 때마다 추가되는 로그이므로 희박합니다. 레코드 크기가 고정되어 있으므로 "가장 가까운 것부터" 표시하도록 역순으로 쉽게 읽을 수 있습니다.
두 파일 모두 동일한 레코드 형식을 가지므로 이를 사용하여 특정 파일을 읽을 수 있습니다.less -f /var/log/whatever
그렇다면 아무런 해를 끼치 지 않을 것입니다.wtmp 예홀은 단순히 전체 바이트 0으로 읽고 무시되기 때문에 희박합니다. 그러나 이 취약점은 갑작스러운 시스템 종료(메타데이터가 새로 고쳐졌으나 콘텐츠가 손실됨)로 인한 기록 손실을 나타낼 수 있습니다.
접미사가 붙은 변형은 x더 큰 레코드 구조를 가지지만(이전 변형은 전체 IPv6 주소 또는 합리적인 FQDN을 위한 공간이 없었음) 그 외에는 유사하게 동작합니다. 일부 버전에서는 last두 레코드 구조를 모두 읽을 수 있습니다.