RAIDiator OS के तहत ext3 फाइल सिस्टम पर रूट उपयोगकर्ता के रूप में एक निर्देशिका में केवल एक फ़ाइल के लिए अनुमति से इनकार किया गया

Question

मेरे पास एक "स्टोरेज" नाम का रेडीएएनएएस बॉक्स है जो मुझे लगता है कि डेबियन पर आधारित है। मैं इसे जड़ के रूप में बहा सकता हूं। मैं वेबसर्वर को फिर से कॉन्फ़िगर करने की कोशिश कर रहा हूं, लेकिन मैं एक फ़ाइल अनुमतियों की समस्या में चल रहा हूं जो मुझे समझ में नहीं आता है। मैं /etc/frontview/apache/apache.pemजड़ के रूप में भी कुछ नहीं कर सकता ! यह उसी निर्देशिका में अन्य फ़ाइलों की तुलना में कोई विशेष अनुमति नहीं देता है और मैं उन लोगों के साथ काम कर सकता हूं।

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

इस फाइल में ऐसा क्या खास है कि इसे छुआ नहीं जा सकता? मैं इसे हटा नहीं सकता। मैं इस पर अनुमति नहीं बदल सकता। मैं इसके मालिक को नहीं बदल सकता।

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

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /

Comments

कृपया ls -ld /etc/frontview/apacheऔर का उत्पादन भी दिखाएं df /etc/frontview/apache। हो सकता है कि फ़ोल्डर डिस्क स्थान पर लगा हो ro?

— नेड64

मैंने उस जानकारी को प्रश्न में जोड़ दिया। यह सब मुझे ठीक लगता है। किसी भी मामले में, अगर यह समस्या थी, तो मुझे नहीं लगता कि मैं उस निर्देशिका में हर दूसरी फ़ाइल को संपादित कर सकता हूं।

— स्टीफन ओस्टरमिलर

@RunCMD मैंने शीर्षक और टैग में अधिक विशिष्ट जानकारी जोड़ी। फाइलसिस्टम को ext3 के रूप में सूचीबद्ध किया गया है, इसलिए ext3 अपरिवर्तनीय का समर्थन करता दिखाई देगा # mount:/dev/hdc1 on / type ext3 (rw,noatime)

— स्टीफन ओस्टरमिलर

Solaris ext3 का समर्थन नहीं करता है और न ही ARM cpu का ताकि यह संभवतः Solaris पर आधारित न हो।

— alanc

मैंने सोलारिस को सवाल से हटा दिया। आगे पढ़ने पर यह डेबियन एच पर आधारित हो सकता है।

— स्टीफन ओस्टरमिलर

Answer 1

मुझे सिर्फ समस्या मिली। उस फ़ाइल पर "अपरिवर्तनीय" विशेषता सेट की गई थी। lsयह नहीं दिखाता है। इसे देखने के लिए आपको एक अलग कमांड की आवश्यकता है:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

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

# chattr -i apache.pem
# touch apache.pem

Comments

मैं इस सवाल पर क्लिक करके "हॉट नेटवर्क प्रश्न" में आपको विस्तारित-विशेषताओं की जांच करने के लिए कहता हूं, लेकिन मुझे लगता है कि आपने पहले ही किया था। (आईडीके जीएनयू में lsविशेषताओं को सूचीबद्ध करने का विकल्प क्यों नहीं है। मैं भूल जाता हूं, लेकिन शायद उन्हें क्वेरी करने के लिए सिस्टम कॉल पोर्टेबल नहीं है, इसलिए शायद उन्हें अलग उपयोगिता में लागू करना आसान था।)

— पीटर कॉर्ड्स

@PeterCordes मैं सहमत हूं। मुझे यकीन है कि मैंने "ओवरराइटिंग फ़ाइल से अपग्रेड को रोकना" जैसी किसी चीज़ को गुग्लिंग के बाद सेट कर दिया था, लेकिन यह वर्षों पहले था और मैं स्पष्ट रूप से इसे भूल गया था। अच्छा होगा अगर lsउस बिट को दिखाया जाए, या मेरे द्वारा उपयोग की गई अन्य कमांड्स में से कोई भी अधिक सहायक (और विशिष्ट) त्रुटि संदेश था कि अनुमति क्यों अस्वीकार की गई थी।

— स्टीफन ओस्टरमिलर

सभी touchजानते हैं कि सिस्टम ने इसे प्रयास किया ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) विफल रहा EACCESS। ( strace -efile touch apache.pemफ़ाइल से संबंधित सिस्टम कॉल यह देखने के लिए उपयोग करें )। जैसा कि उस सिस्टम कॉल के लिए मैन पेज कहता है , EACCESS के कई संभावित कारण हैं, और उनमें से कई में फ़ाइल के बजाय मूल निर्देशिका शामिल है। कोड लिखना सटीक रूप से कम करने के लिए कि सिस्टम कॉल ने त्रुटि को क्यों लौटाया, यह बहुत कठिन होगा, क्योंकि विभिन्न फाइल सिस्टम और ओएस अलग-अलग हैं ...

— पीटर कॉर्ड्स

वैसे भी, सार्वभौमिक सम्मेलन यह है कि जब कुछ विफल होता है, तो आप त्रुटि कोड ( errno) के लिए त्रुटि स्ट्रिंग को देखते हैं और प्रिंट करते हैं। (सी मानक पुस्तकालय perrorसमारोह, या समकक्ष का उपयोग करना )। यह उन दुर्लभ मामलों में से एक है जहां उपयोगकर्ता को समस्या का जल्द पता लगाने के लिए यह हमेशा पर्याप्त नहीं होता है, लेकिन अधिकांश समय यह बहुत अच्छी तरह से काम करता है। (खासकर जब straceमामले में संयुक्त रूप से कोई संदेह है कि किस ऑपरेशन ने त्रुटि उत्पन्न की है।) यह बिल्कुल सही नहीं है, लेकिन यह बहुत बुरा हो सकता है (cf. एमएस विंडोज जहां सबसे अच्छा आपको Google पर एक त्रुटि कोड मिलता है।)

— पीटर कॉर्ड्स

बस के साथ खेल रहा था chattr +i, और देखा कि rm foo(बिना -f) संकेत देता है rm: remove write-protected regular file ‘foo’:। क्योंकि faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied)। POSIX को rmराइट-प्रोटेक्टेड फाइल्स को हटाने से पहले डिफ़ॉल्ट रूप से प्रॉम्प्ट करने की आवश्यकता होती है, और यही वजह है कि यह पहली बार में चेक करता है। यदि आप इस्तेमाल नहीं किया था तो आप तेजी से एक बड़ा सुराग मिल गया होता rm -f। : / access(3)कर्नेल को अनुमतियों की जांच करने के लिए कहता है जैसे कि यह वास्तव में लिखने के लिए खुल रहा था, इसलिए यह एसीएल और विशेषताओं को चुनता है।

— पीटर कॉर्ड्स