ऐसी फाइलें खोजें, जिन्हें कोई उपयोगकर्ता नहीं पढ़ सकता है?

12

मैं ऐसी फाइलें ढूंढना चाहता हूं जो एक विशेष उपयोगकर्ता नहीं पढ़ पाएगा।

मान लें कि उपयोगकर्ता नाम "user123" है और वे "user123" नामक समूह में हैं। मैं उन फ़ाइलों को ढूंढना चाहता हूं, अगर वे user123 के स्वामित्व में हैं, तो उनके पास u + r है; यदि यह विफल रहता है कि फ़ाइल समूह का उपयोगकर्ता नाम है तो उस पर g + r होना चाहिए; विफल रहा है कि यह ओ + आर पर हो सकता है।

चूंकि जीएनयू में "-अर्थ्य" है, इसलिए मैं ऐसा कर सकता था:

sudo -u user123 find /start ! -readable -ls

हालाँकि इस प्रक्रिया को एक उपयोगकर्ता द्वारा चलाना पड़ता है जिसमें सुडो एक्सेस नहीं है। इसलिए II ने यह कोशिश की: (यह ओ + आर की जांच नहीं करता है लेकिन यह इस बिंदु पर महत्वपूर्ण नहीं है)

find /start \( -user user123 ! -perm -u=r  \) -o \( -group user123 ! -perm -g=r  \) -ls

लेकिन यह इस फ़ाइल को सूचीबद्ध करता है:

272118    4 -rw-------   1 user123   user123       3243 Jul  3 19:50 /start/blah/blah/file.txt

यह फ़ाइल एकमात्र ऐसी फ़ाइल है जिसके /startस्वामित्व में उपयोगकर्ता नाम g=rबंद है। यह ऐसा लगता है जैसे खोज के -u=rरूप में व्याख्या कर रहा है -g=r।

मैंने तर्क को उलटने की कोशिश करने का फैसला किया और इसके बजाय परीक्षण not ( truth )किया:

find /etc/puppet ! \( \( -user puppet -perm -u=r  \) -o \( -group puppet -perm -g=r \) -o \( -perm -o=r \) \)  -ls

यह काम करता है!

मूल findअसफल क्यों हुआ ? क्या यह एक बग find(असंभावित) है या तर्क गलत है?

अपडेट: मेरे पास तर्क गलत था। जैसा कि नीचे बताया गया है, जब से! (ए || बी। सी।) == (! & A! & B! B &&! C) ये दो समतुल्य कथन हैं:

find /start ! \( \( -user user123 -perm -u=r \) -o \( -group user123 -perm -g=r \) -o \( ! \( -user user123 -o -group user123 \) -perm -o=r \) \) -ls
find /start ! \( -user user123 -perm -u=r \) ! \( -group user123 -perm -g=r \) ! \( ! \( -user user123 -o -group user123 \) -perm -o=r \) -ls

मेरा लक्ष्य दो बार उपयोगकर्ता / समूह का परीक्षण करना नहीं था। मुझे वास्तव में जरूरत है कि एक और अधिक जटिल है अगर-तब-और संरचना, जो शायद केवल तभी संभव होगी जब एक -x ऑपरेटर था। मैं एक xor का निर्माण कर सकता हूं और / या नहीं, लेकिन यह ऊपर दिए गए दो समाधानों से अधिक जटिल होगा।

find

— TomOnTime
स्रोत

1

यहां तक कि दूसरा तर्क गलत है, क्योंकि यह कहेगा कि puppetइसके साथ एक फ़ाइल तक पहुंच होगी --wxrwxrwx puppet puppet।

— स्टीफन चेज़लस

7

तर्क गलत है। आप सोच रहे हैं कि यह फ़ाइल सूचीबद्ध नहीं होनी चाहिए क्योंकि यह user123उपयोगकर्ता के पास है और उपयोगकर्ता के rबिट सेट है। हालाँकि, इसे सूचीबद्ध किया गया है क्योंकि यह दूसरी कसौटी से मेल खाता है (यह समूह के स्वामित्व में है user123और समूह का rथोड़ा परेशान है)।

आपका दूसरा संस्करण डे मॉर्गन के कानूनों में से एक के कारण काम करता है : बयानों के एक समूह के तार्किक ओरिंग को नकारना तार्किक रूप से व्यक्तिगत बयानों की उपेक्षा के बराबर है। दूसरे शब्दों में:

 ! ( A || B || C ) == ( !A && !B && !C )

तो काम findएक फ़ाइल के लिए देख रहा है कि

(उपयोगकर्ता द्वारा स्वामित्व user123और कहा उपयोगकर्ता द्वारा पठनीय नहीं है) और
(समूह द्वारा user123और पढ़ने योग्य समूह के स्वामित्व में नहीं है ) और
विश्व-पठनीय नहीं है

जबकि पहले findएक फ़ाइल की तलाश में है

उपयोगकर्ता के स्वामित्व में है user123और कहा गया है या उपयोगकर्ता द्वारा पठनीय नहीं है
समूह के स्वामित्व में है user123और उक्त समूह द्वारा पठनीय नहीं है (या यदि आपने इसे पूरा कर लिया है)
विश्व-पठनीय नहीं है

तो उपरोक्त 3 मानदंड (और जरूरी नहीं कि सभी) में से किसी से मेल खाते हुए फ़ाइल को आपके द्वारा देखे गए के रूप में सूचीबद्ध किया जाएगा।

संपादित करें

संयोग से (आपकी प्रोफ़ाइल देखने के बाद), मैं आपकी ओ'रिली किताब का बहुत बड़ा प्रशंसक हूं :)

— जोसेफ आर।
स्रोत

विश्लेषण के लिए धन्यवाद। हां, यह मॉर्गन के कानून का गलत इस्तेमाल था। मैं करने की कोशिश कर रहा था, ( !A && !B && !C )लेकिन मैं !प्रत्येक भाग के आंतरिक भाग में चला गया , जो मान्य नहीं है। धन्यवाद!

— टॉमऑन टाइम

PS मुझे खुशी है कि आप मेरी किताब के प्रशंसक हैं! मैं उत्सुक हूं कि आप इसे किस भाषा में पढ़ते हैं।

— टॉमऑनटाइम

@TomOnTime अंग्रेजी, निश्चित रूप से। मैं किसी भी पुस्तक को उसकी मूल भाषा में पढ़ने की कोशिश करता हूं अगर मैं उसकी मदद कर सकता हूं।

— जोसेफ आर।

8

उपयोगकर्ता द्वारा किसी दिए गए रास्ते से किसी फ़ाइल तक पहुँच है या नहीं, यह जाँचने के लिए और भी बहुत सी बातें हैं।

फ़ाइल का स्वामी
फ़ाइल का समूह
फ़ाइल में ACLs
यूआईडी, जीआईडी, और उपयोगकर्ता के पूरक ग्रिड
उस फ़ाइल के लिए अग्रणी किसी भी पथ घटक की खोज।
क्या फ़ाइल एक सिमिलिंक है
आईडी 0 के उपयोगकर्ताओं के लिए अनुमतियां अलग-अलग लागू होती हैं।
संभवतः SELinux जैसी अधिक सुरक्षा सुविधाएँ ...

वास्तव में उपयोगकर्ता के सभी uids और gids को स्विच करना और जाँचना, यह सिस्टम क्या करता है, उसी तर्क को लागू करना बहुत मुश्किल है।

Zsh के साथ, आप कर सकते हैं (रूट के रूप में):

readable() (
  USERNAME=$u
  [ -r "$REPLY" ]
)
u=some-user
print -rl -- **/*(DoN^+readable)

या साथ perl:

find . -print0 | sudo -u some-user perl -Mfiletest=access -l -0ne '
  print unless -r'

यह दोनों ही मामलों में, डायरेक्टरी ट्री को उतारा जाता है, rootलेकिन संबंधित यूजर के रूप में फाइल एक्सेस के लिए टेस्ट किया जाता है।

ऐसे मामलों में नहीं चल रहा है find -readableक्योंकि some-userयह उन निर्देशिकाओं को पार करने में सक्षम नहीं होगा जिनके लिए उपयोगकर्ता की कोई पहुंच नहीं है या कोई पढ़ने की अनुमति नहीं है (लेकिन संभवतः पहुंच)।

यहां तक कि जब केवल फ़ाइल की अनुमति और स्वामित्व पर ही विचार करना चाहिए (और एसीएल या पथ घटकों ...) नहीं, तो आपको कम से कम (यहां जीएनयू सिंटैक्स) की आवश्यकता है:

u=some-user; g=$(id -G "$u" | sed 's/ / -o -group /g'); IFS=" "
find . ! \( -user "$u" -perm -u=r -o \
          ! -user "$u" \( -group $g \) -perm -g=r -o \
          ! -user "$u" ! \( -group $g \) -perm -o=r \)

यह विचार यह है कि यदि फ़ाइल उपयोगकर्ता के स्वामित्व में है, तो अन्य सभी अनुमतियाँ अप्रासंगिक हैं। यदि नहीं, तो यदि फ़ाइल उपयोगकर्ता के किसी समूह के समूह के स्वामित्व में है, तो "अन्य" अनुमति अप्रासंगिक है।

— स्टीफन चेज़लस
स्रोत

1

एसीएल और अन्य कारकों के बारे में अच्छी बात है। केवल 100% सही मूल्यांकन है access()क्योंकि यह उसी कर्नेल कोड का उपयोग करता है open()। इस प्रकार एक विकल्प है sudo -u user123 find /start -readableतो सबसे अच्छा समाधान sudoहै।

— टॉमऑनटाइम

1

@TomOnTime। ठीक है, यदि आप उपयोग करते हैं sudo -u user123 find -readable, तो यह उन निर्देशिकाओं में फ़ाइलों की रिपोर्ट नहीं करेगा जिन्हें आप दर्ज नहीं कर सकते हैं, या उन निर्देशिकाओं में जिन्हें आप पढ़ नहीं सकते हैं (इसलिए झूठी नकारात्मक और गलत सकारात्मकताएं होंगी)। यही कारण है कि मैं zshडायरेक्टरी ट्री को रूट और डू access()( [ -r ... ]) वास्तविक उपयोगकर्ता के रूप में उपयोग करने के लिए उपयोग करने का सुझाव देता हूं ( सभी uids और जैसे परिवर्तन $USERNAMEमें सेटिंग )। zshsudo

— स्टीफन चेज़लस