whatfiles

Whatfiles는 다른 프로그램이 시스템에서 어떤 파일을 읽고/쓰고/생성하고/삭제하는지 기록하는 Linux 유틸리티입니다. 대상 프로세스에 의해 생성된 모든 새로운 프로세스와 스레드도 추적하며, 각 작업의 성공 여부를 기록합니다.

이유:

main()부터 종료까지 프로세스가 어떤 파일을 건드리는지 확인할 수 있는 간단한 유틸리티가 없다는 점에 오랫동안 답답함을 느껴왔습니다. 소프트웨어 벤더를 신뢰하지 않든, 멀웨어가 걱정되든, 프로그램이나 설치 프로그램이 시스템에 무엇을 하는지 아는 것은 중요합니다. lsof는 특정 시점만 관찰하고 strace는 크고 다소 복잡합니다.

출력 예시:

mode:   exec, file: /usr/bin/cp, syscall: execve(), PID: 17004, process: sh, result: 0
mode:   read, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: -1 (No such file or directory)
mode:   read, file: /etc/hostname, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 3
mode: write+create, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 4
mode:  chmod, file: /tmp/demo/copy.txt, syscall: fchmodat(), PID: 17005, process: /usr/bin/chmod, result: 0
mode: rename, file: /tmp/demo/copy.txt, to: /tmp/demo/renamed.txt, syscall: renameat2(), PID: 17006, process: /usr/bin/mv, result: 0
mode:   read, file: /tmp/demo/missing.txt, syscall: openat(), PID: 17007, process: /usr/bin/cat, result: -1 (No such file or directory)
mode: delete, file: /tmp/demo/renamed.txt, syscall: unlinkat(), PID: 17008, process: /usr/bin/rm, result: 0

각 줄은 파일에 수행된 작업, 파일 자체, 어떤 syscall이 수행했는지, 어떤 프로세스와 스레드인지, 그리고 커널이 무엇을 반환했는지를 나타냅니다. 경로는 항상 절대 경로입니다: 상대 경로는 프로세스의 작업 디렉터리를 기준으로, 또는 *at() syscall에 전달된 디렉터리를 기준으로 해석됩니다. result는 syscall의 반환값이므로, 실패한 접근과 성공한 접근을 구분할 수 있습니다.

열기, 생성, 삭제 외에도 whatfiles는 프로그램의 rename, link, symlink, mkdir, rmdir, truncate, chmod, chown, exec를 보고합니다. SYSCALLS.md는 아직 보고되지 않은 것들과 각 추가가 왜 가치 있는지를 다룹니다.

사용법:

기본 사용법, ls를 실행하고 현재 디렉터리의 로그 파일에 출력을 기록합니다:

$ whatfiles ls -lah ~/Documents
-o로 출력 파일 위치 지정:

$ whatfiles -o MyLogFile cd ..
디버그 출력 포함, 로그 파일 대신 stdout으로 출력:

$ whatfiles -d -s apt install zoom
현재 실행 중인 프로세스에 연결 (root 권한 필요):

$ sudo whatfiles -p 1234
whatfiles 자체가 종료될 경우 추적 중인 프로그램을 추적되지 않은 채로 계속 실행하지 않고 함께 종료:

$ whatfiles -k ./installer.sh

언제든지 Ctrl-C를 누르세요: whatfiles는 추적 중인 모든 것에서 분리되고, 해당 프로세스들은 계속 실행되도록 두며, 로그 작성을 마칩니다.

배포

바로 사용할 수 있는 바이너리는 releases 페이지에 있습니다! 누군가 친절하게도 Arch 저장소에 추가했으며, letompouce가 GitLab 파이프라인도 설정했습니다.

컴파일 (`gcc`와 `make` 필요):

$ cd whatfiles
$ make
$ sudo make install

x86, x86_64, ARM32, ARM64 아키텍처를 지원합니다. make install은 PREFIX와 DESTDIR을 존중합니다.

Linux 3.4 이상이 필요합니다. Linux 5.3 이상에서는 whatfiles가 각 syscall 중단에 대해 커널에 직접 질의하는데, 이것이 64비트 머신에서 32비트 syscall이 올바르게 디코딩되도록 합니다; 이전 커널에서는 레지스터를 읽는 방식으로 대체합니다.

Android

NDK로 크로스 컴파일한 다음, 바이너리를 기기로 푸시합니다:

$ make android NDK=~/Android/Sdk/ndk/<version>
$ adb push bin/whatfiles-android /data/local/tmp/whatfiles
$ adb shell chmod 755 /data/local/tmp/whatfiles
$ adb shell /data/local/tmp/whatfiles -o /data/local/tmp/ls.log ls /sdcard

ANDROID_ABI는 기본값인 arm64 또는 arm32, x86_64, x86을 선택합니다. ANDROID_API는 최소 API 레벨을 설정하며 기본값은 21입니다.

기기에서는 몇 가지가 다릅니다:

바이너리를 /data/local/tmp에 두세요. /sdcard는 실행 권한 없이 마운트됩니다.
adb shell의 작업 디렉터리는 쓰기 가능하지 않으므로, /data/local/tmp 아래의 경로와 함께 -o를 전달하거나, stdout에 쓰려면 -s를 전달하세요.
whatfiles 아래에서 명령을 실행하는 것은 일반 셸 사용자로 동작하며, 그 사용자가 시작한 프로세스에 연결하는 것도 마찬가지입니다. 그 외의 것, 예를 들어 앱에 연결하려면 root가 필요하므로 userdebug 빌드에서는 adb root를 사용하세요. Android 14 에뮬레이터에서는 SELinux가 enforcing 상태에서도 동작했습니다; 프로덕션 기기의 정책은 여전히 거부할 수 있습니다.
make test-android NDK=~/Android/Sdk/ndk/<version>는 연결된 기기용으로 whatfiles와 테스트 프로그램을 빌드하고, 그곳에서 검사를 실행하며, 푸시한 것을 제거합니다.
arm64 빌드에서 추적된 32비트 앱은 64비트로 간주되지 않고 32비트 syscall 번호와 인자 레지스터로 읽힙니다. 이 경로는 실제 하드웨어에서 검증되지 않았습니다: 여기서 테스트에 사용된 에뮬레이터에는 32비트 ABI가 없습니다.

make test는 tests/의 프로그램을 빌드하고 whatfiles 아래에서 실행하여 시그널 전달, 스레드 및 자식 프로세스 커버리지, 인터럽트 처리를 포함한 동작을 확인합니다.

언젠가 질문받을 수 있는 것들:

이건 그냥 strace -fe trace=creat,open,openat,unlink,unlinkat ./program의 재구현이 아닌가요?

맞습니다. 다만 더 단순하고 사용자 친화적이 되도록 목표합니다.
Mac과 Windows 버전이 있나요?

없습니다. Mac에서 syscall을 추적하려면 task_for_pid()가 필요하고, 이는 코드 서명이 필요하며, 작동하게 만들 수 없었고, 어쨌든 무료 소프트웨어를 작성하기 위해 Apple에 연 100달러를 지불할 의향이 없습니다. Mac의 dtruss는 단일 프로세스와 그 자식들을 따라가는 데 사용할 수 있지만, -t 플래그는 필터링할 단일 syscall만 받는 것 같습니다. fs_usage도 비슷한 일을 하지만 자식 프로세스/스레드를 따라가는지는 확실하지 않습니다. Windows용 Process Monitor는 꽤 훌륭합니다.

제한 사항:

자기 자신의 복사본에 작업을 넘기는 프로그램. 특히 브라우저: 인스턴스가 이미 실행 중이면, 실행한 인스턴스가 요청을 그쪽으로 전달하고 종료하므로 whatfiles는 추적할 것이 남지 않아 중지되며, 요청한 창은 추적되지 않은 복사본에서 나옵니다. 대신 별도의 인스턴스를 추적하세요, 예를 들어 whatfiles firefox --no-remote --profile ~/ff-trace-profile와 아직 존재하지 않는 프로필 디렉터리를 사용하거나, 실행 중인 복사본을 먼저 종료하세요.
보안 경계가 아닙니다. 감시받기를 원하지 않는 프로그램은 자신이 추적되고 있음을 알 수 있으며, io_uring은 whatfiles가 감시하는 syscall 없이 파일 작업을 수행합니다. 로그를 프로그램이 한 일에 대한 설명으로 취급하고, 프로그램이 할 수 있었던 모든 것에 대한 증거로 취급하지 마세요.
속도. 모든 syscall은 추적된 프로세스를 두 번 중단시키므로, syscall이 많은 프로그램은 평소보다 몇 배 느리게 실행됩니다. 이는 모든 syscall을 따라갈 때 strace가 지불하는 것과 동일한 비용입니다.
연결에는 권한이 필요합니다. -p는 일반적으로 root, 또는 완화된 /proc/sys/kernel/yama/ptrace_scope가 필요합니다. 연결이 거부되면 대상은 정상적으로 계속 실행됩니다.
whatfiles가 SIGKILL로 즉시 종료되면, 추적하던 프로그램은 -k로 시작되지 않은 한 추적되지 않은 채로 계속 실행됩니다.

계획된 기능:

현재는 없음, 요청과 PR을 환영합니다.

관심 가져주셔서 감사합니다, 그리고 Cloaker, Nestur, Flying Carpet도 확인해 보세요!

whatfiles v2.0

카테고리