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

प्रत्येक पंक्ति बताती है कि फ़ाइल के साथ क्या किया गया, फ़ाइल स्वयं, किस सिस्टम कॉल ने यह किया, कौन सी प्रक्रिया और थ्रेड, और कर्नेल ने क्या लौटाया। पथ हमेशा निरपेक्ष होते हैं: सापेक्ष पथ प्रक्रिया की कार्यशील निर्देशिका के सापेक्ष, या उस निर्देशिका के सापेक्ष हल किए जाते हैं जिसे उसने *at() सिस्टम कॉल को पास किया था। result सिस्टम कॉल का रिटर्न मान है, इसलिए असफल और सफल पहुँच को अलग किया जा सकता है।

खोलने, बनाने और हटाने के अलावा, 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

• वर्तमान में चल रही प्रक्रिया से अटैच करें (रूट विशेषाधिकार आवश्यक):

  $ 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 प्रत्येक सिस्टम कॉल स्टॉप के बारे में सीधे कर्नेल से पूछता है, जिसके कारण 64-बिट मशीन पर 32-बिट सिस्टम कॉल सही ढंग से डिकोड होते हैं; पुराने कर्नेल पर यह रजिस्टर पढ़ने पर वापस चला जाता है।

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 में कार्यशील निर्देशिका लिखने योग्य नहीं है, इसलिए -o के साथ /data/local/tmp के अंतर्गत एक पथ पास करें, या stdout पर लिखने के लिए -s।
• whatfiles के अंतर्गत कमांड चलाना सामान्य शेल उपयोगकर्ता के रूप में काम करता है, और उस उपयोगकर्ता द्वारा शुरू की गई प्रक्रिया से अटैच करना भी। किसी और चीज़ से अटैच करना, उदाहरण के लिए किसी ऐप से, रूट की आवश्यकता है, इसलिए userdebug बिल्ड पर adb root। Android 14 एमुलेटर पर यह SELinux enforcing के साथ काम करता था; उत्पादन डिवाइस की नीति अभी भी मना कर सकती है।
• make test-android NDK=~/Android/Sdk/ndk/<version> कनेक्टेड डिवाइस के लिए whatfiles और परीक्षण प्रोग्राम बनाता है, वहाँ जाँच चलाता है, और जो पुश किया था उसे हटा देता है।
• arm64 बिल्ड से ट्रेस किए गए 32-बिट ऐप को 64-बिट मानने के बजाय 32-बिट सिस्टम कॉल नंबरों और आर्ग्युमेंट रजिस्टरों के साथ पढ़ा जाता है। उस पथ का वास्तविक हार्डवेयर पर परीक्षण नहीं किया गया है: यहाँ परीक्षण के लिए उपयोग किए गए एमुलेटर में कोई 32-बिट ABI नहीं है।

make test tests/ में प्रोग्राम बनाता है और इसके व्यवहार की जाँच के लिए उन्हें whatfiles के अंतर्गत चलाता है, जिसमें सिग्नल डिलीवरी, थ्रेड और चाइल्ड-प्रोसेस कवरेज, और इंटरप्ट हैंडलिंग शामिल है।

प्रश्न जो किसी बिंदु पर पूछे जा सकते हैं:

• क्या यह strace -fe trace=creat,open,openat,unlink,unlinkat ./program का पुनः कार्यान्वयन मात्र नहीं है?

  हाँ। हालाँकि इसका लक्ष्य सरल और अधिक उपयोगकर्ता-मैत्रीपूर्ण होना है।

• क्या Mac और Windows संस्करण हैं?

  नहीं। Mac पर सिस्टम कॉल ट्रेस करने के लिए task_for_pid() आवश्यक है, जिसके लिए कोड साइनिंग आवश्यक है, जिसे मैं काम करवा नहीं पाता, और वैसे भी मुझे मुफ़्त सॉफ़्टवेयर लिखने के लिए Apple को $100/वर्ष देने में कोई रुचि नहीं है। Mac पर dtruss का उपयोग एकल प्रक्रिया और उसके चिल्ड्रन का अनुसरण करने के लिए किया जा सकता है, हालाँकि -t फ़्लैग फ़िल्टर करने के लिए केवल एकल सिस्टम कॉल स्वीकार करता प्रतीत होता है। fs_usage कुछ ऐसा ही करता है हालाँकि मुझे यकीन नहीं है कि यह चाइल्ड प्रोसेस/थ्रेड का अनुसरण करता है या नहीं। Windows के लिए Process Monitor काफ़ी बढ़िया है।

सीमाएँ:

• वे प्रोग्राम जो स्वयं की एक प्रति को सौंप देते हैं। विशेष रूप से ब्राउज़र: यदि कोई इंस्टेंस पहले से चल रहा है, तो आप जिसे लॉन्च करते हैं वह आपके अनुरोध को उसे सौंप देता है और बाहर निकल जाता है, इसलिए whatfiles के पास ट्रेस करने के लिए कुछ नहीं बचता और रुक जाता है, जबकि आपने जिस विंडो के लिए कहा था वह बिना ट्रेस की गई प्रति से आती है। इसके बजाय एक अलग इंस्टेंस को ट्रेस करें, जैसे whatfiles firefox --no-remote --profile ~/ff-trace-profile और एक प्रोफ़ाइल निर्देशिका जो अभी तक मौजूद नहीं है, या पहले चल रही प्रति को बंद कर दें।

• सुरक्षा सीमा नहीं। जो प्रोग्राम देखा जाना नहीं चाहता वह बता सकता है कि उसे ट्रेस किया जा रहा है, और io_uring फ़ाइल ऑपरेशन उन सिस्टम कॉलों के बिना करता है जिन्हें whatfiles देखता है। लॉग को इस बात के विवरण के रूप में लें कि किसी प्रोग्राम ने क्या किया, न कि उस सब के प्रमाण के रूप में जो वह कर सकता था।

• गति। प्रत्येक सिस्टम कॉल ट्रेस की गई प्रक्रिया को दो बार रोकता है, इसलिए सिस्टम कॉल-भारी प्रोग्राम सामान्य से कई गुना धीमे चलते हैं। यह वही लागत है जो strace सभी सिस्टम कॉलों का अनुसरण करते समय चुकाता है।

• अटैच करने के लिए विशेषाधिकार चाहिए। -p को आम तौर पर रूट, या एक शिथिल /proc/sys/kernel/yama/ptrace_scope आवश्यक होता है। अस्वीकृत अटैच लक्ष्य को सामान्य रूप से चलते हुए छोड़ देता है।

• यदि whatfiles को सीधे मार दिया जाए SIGKILL के साथ, तो जिस प्रोग्राम को यह ट्रेस कर रहा था वह बिना ट्रेस के चलता रहता है, जब तक कि इसे -k के साथ शुरू न किया गया हो।

नियोजित विशेषताएँ:

• वर्तमान में कोई नहीं, अनुरोधों और PRs के लिए खुला हूँ।

आपकी रुचि के लिए धन्यवाद, और कृपया Cloaker, Nestur, और Flying Carpet भी देखें!