क्या सुपर यूजर केवल पढ़ने वाली फाइलों में लिख सकता है?

Question

मैंने FreeBSD पर आश्चर्य व्यवहार (मेरे लिए) अनुमति व्यवहार पर ठोकर खाई है। मान लें कि मैं गैर-रूट उपयोगकर्ता के रूप में काम कर रहा हूं । मैं एक फ़ाइल बनाता हूं, इसकी अनुमति केवल पढ़ने के लिए देता हूं और फिर उसमें लिखने का प्रयास करता हूं:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

अब तक सब ठीक है। अब मैं रूट के समान करता हूं और यह फाइल में लिखता है:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

क्या यह बग या इच्छित व्यवहार है? क्या मैं सुरक्षित रूप से मान सकता हूं कि यह किसी भी यूनिक्स और लिनक्स पर काम करेगा?

Comments

कोई भी उपयोगकर्ता CAP_DAC_OVERRIDEऐसा कर सकता है। लगभग सभी लिनक्स सिस्टम पर इसका मतलब है कि रूट ऐसा कर सकता है इसलिए यह जानबूझकर है। FreeBSD भाग के लिए बात नहीं कर सकते, लेकिन मुझे लगता है कि वे एक समान सेटअप है।

— ब्राचली

मूल कारण ALWAYS को एक फ़ाइल में लिखने में सक्षम होना चाहिए क्योंकि पारंपरिक यूनिक्स फाइल सिस्टम (ext4, zfs आदि) पर फ़ाइल अनुमतियाँ फ़ाइल का हिस्सा हैं। इसलिए यदि रूट फ़ाइल में नहीं लिख सकता है, तो NOBODY फिर से केवल फ़ाइल को लिखने योग्य बना chmodसकता है क्योंकि फ़ाइल में नहीं लिख सकता।

— स्लीपबेटमैन

@slebetman आपको अनुमतियों को अद्यतन करने के लिए किसी फ़ाइल तक पहुंच की आवश्यकता नहीं है। बस touch somefile; chmod 0000 somefile; chmod 0644 somefileएक सामान्य उपयोगकर्ता के रूप में प्रयास करें।

— user253751

@ मिनीबिस: कि आप खुद। रूट को फाइलों पर उन अनुमतियों को बदलने में सक्षम होने की आवश्यकता है जो यह स्वयं नहीं करता है

— स्लीबेटमैन

@slebetman हाँ ... लेकिन आप उन फ़ाइलों पर अनुमतियों को बदलने के बारे में बात कर रहे थे जिन्हें आप नहीं लिख सकते, न कि आपके पास मौजूद फ़ाइल पर अनुमतियों को बदलने के बारे में।

— user253751

Answer 1

rootइस तरीके से अनुमतियों को ओवरराइड करने में सक्षम होना सामान्य है।

एक अन्य उदाहरण rootएक फ़ाइल को पढ़ने में सक्षम नहीं होने के साथ पढ़ने में सक्षम हो रहा है:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

कुछ प्रणालियों में अपरिवर्तनीय फ़ाइलों की अवधारणा है । FreeBSD पर उदा:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

अब rootफाइल पर लिख भी नहीं सकते। लेकिन, निश्चित रूप से, झंडा हटाroot सकते हैं :

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

FreeBSD के साथ आप एक कदम आगे जा सकते हैं और ध्वज को rootहटाने से रोकने के लिए एक कर्नेल ध्वज सेट कर सकते हैं :

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

अब कोई नहीं, rootइस फाइल को बदल भी नहीं सकता।

(सिक्योरवेल को कम करने के लिए सिस्टम को रीबूटिंग की आवश्यकता होती है)।

Comments

रिबूट को प्रभावी सुरक्षा उपाय की आवश्यकता कैसे होती है? इसके अलावा, अगर रूट रूट है और कुछ भी कर सकता है, तो रूट को रूट करने से रोकने की कोशिश करने से क्यों परेशान होता है?

— बिल्ली

एक सुरक्षित प्रणाली पर, जड़ है नहीं भगवान की तरह। फ्रीबीएसडी सिक्योरवेल रूट कम भगवान की तरह बनाने के लिए एक छोटा सा प्रयास है। सिक्योरवेल को सिस्टम कॉन्फिग में डिफॉल्ट 1 पर सेट किया जा सकता है ताकि रिबूट के बाद भी यह एक्टिव रहे। तो फिर इसे कंसोल एक्सेस और सिंगल यूजर मोड की आवश्यकता होगी और यह बहुत स्पष्ट है। यूनिक्स सुरक्षा के आसपास एक पूरा निबंध है जो एसई टिप्पणी क्षेत्र के लिए बहुत अधिक है, लेकिन हम एक 'रूट से सभी एक्सेस' मॉडल को कुछ अधिक बारीकियों में ले जाने की कोशिश कर रहे हैं। हम जहां संभव हो सके (जैसे सिक्योरवेल) को लागू करने की कोशिश करते हैं और पता लगाते हैं कि कहां नहीं (रिबूट साक्ष्य, ऑडिट ट्रेल्स)।

— स्टीफन हैरिस

लिनक्स में FWIW, अपरिवर्तनीय विशेषता chattr +i tstनिर्धारित करता है।

— रुस्लान

Answer 2

हां, यह बहुत सामान्य है। जड़ की पढ़ने / लिखने की कोई सीमा नहीं है (बहुत कम अपवाद के साथ), क्योंकि वह जड़ है।