Die Berechtigung wurde nur für eine einzelne Datei in einem Verzeichnis als Root-Benutzer in einem ext3-Dateisystem unter RAIDiator OS verweigert

Ich habe eine ReadyNAS-Box mit dem Namen "Speicher", von der ich glaube, dass sie auf Debian basiert. Ich kann als root hinein ssh. Ich versuche, den Webserver neu zu konfigurieren, stoße jedoch auf ein Dateiberechtigungsproblem, das ich einfach nicht verstehe. Ich kann /etc/frontview/apache/apache.pemauch mit root nichts anfangen! Es scheint keine besonderen Berechtigungen im Vergleich zu anderen Dateien im selben Verzeichnis zu haben, und ich kann damit arbeiten.

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

Was ist das Besondere an dieser Datei, dass sie nicht berührt werden kann? Ich kann es nicht löschen. Ich kann die Berechtigungen dafür nicht ändern. Ich kann den Besitzer nicht ändern.

Das Verzeichnis scheint in Ordnung zu sein. Es hat noch Platz, es ist nicht schreibgeschützt. Tatsächlich kann ich andere Dateien im selben Verzeichnis bearbeiten.

# 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% /

— Stephen Ostermiller
quelle

Bitte zeigen Sie auch die Ausgabe von ls -ld /etc/frontview/apacheund df /etc/frontview/apache. Möglicherweise befindet sich der Ordner auf einem bereitgestellten Speicherplatz ro?

— Ned64

Ich habe diese Informationen zur Frage hinzugefügt. Für mich sieht alles gut aus. Wenn das das Problem wäre, würde ich auf keinen Fall glauben, dass ich jede andere Datei in diesem Verzeichnis bearbeiten könnte.

— Stephen Ostermiller

@ RunCMD Ich habe dem Titel und den Tags spezifischere Informationen hinzugefügt. Das Dateisystem wird als ext3 aufgelistet, so ext3 erscheinen würde unveränderlich zu unterstützen: # mount:/dev/hdc1 on / type ext3 (rw,noatime)

— Stephen Ostermiller

Solaris unterstützt weder ext3 noch ARM-CPUs, daher basiert das wahrscheinlich nicht auf Solaris.

— Alanc

Ich habe Solaris aus der Frage entfernt. Bei weiterer Lektüre kann es auf Debian Etch basieren.

— Stephen Ostermiller

Ich habe gerade das Problem gefunden. Das Attribut "unveränderlich" wurde für diese Datei festgelegt. lszeigt es nicht. Sie benötigen einen anderen Befehl, um ihn anzuzeigen:

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

Sobald ich das unveränderliche Bit entfernt habe, kann ich diese Datei bearbeiten:

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

— Stephen Ostermiller
quelle

Ich habe auf diese Frage in den "Hot Network-Fragen" geklickt, um Ihnen zu sagen, dass Sie die erweiterten Attribute überprüfen sollen, aber ich denke, Sie haben es bereits getan. (IDK, warum GNU lskeine Option zum Auflisten von Attributen hat. Ich vergesse, aber vielleicht ist sogar der Systemaufruf zum Abfragen nicht portierbar, sodass es wahrscheinlich einfacher war, sie nur in einem separaten Dienstprogramm zu implementieren.)

— Peter Cordes

@ PeterCordes Ich stimme zu. Ich bin mir sicher, dass ich dieses Bit nach dem Googeln so etwas wie "Upgrade vom Überschreiben der Datei beenden" gesetzt habe, aber das war vor Jahren und ich habe es eindeutig vergessen. Es wäre schön, wenn lsdas Bit angezeigt würde oder wenn einer der anderen Befehle, die ich verwendet habe, hilfreichere (und spezifischere) Fehlermeldungen darüber enthält, warum die Berechtigungen verweigert wurden.

— Stephen Ostermiller

Alles touchweiß ist, dass der Systemaufruf, mit dem versucht wurde ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)), fehlgeschlagen ist EACCESS. (Verwenden Sie strace -efile touch apache.pemdiese Option , um die dateibezogenen Systemaufrufe anzuzeigen.) Wie in der Manpage für diesen Systemaufruf angegeben , gibt es viele mögliche Gründe für EACCESS, und viele davon betreffen übergeordnete Verzeichnisse und nicht die Datei selbst. Das Schreiben von Code, um genau zu bestimmen, warum ein Systemaufruf den Fehler zurückgegeben hat, wäre extrem schwierig, da verschiedene Dateisysteme und Betriebssysteme unterschiedlich sind ...

— Peter Cordes

Wie auch immer, die universelle Konvention lautet: Wenn etwas fehlschlägt, suchen Sie die Fehlerzeichenfolge nach dem Fehlercode ( errno) und drucken diese aus. (Verwenden der C-Standardbibliotheksfunktion perroroder einer gleichwertigen Funktion). Dies ist einer der seltenen Fälle, in denen dies nicht immer als Hinweis für den Benutzer ausreicht, um das Problem schnell zu finden, aber meistens funktioniert es sehr gut. (Insbesondere in Kombination mit, stracefalls Zweifel darüber bestehen, welche Operation den Fehler verursacht hat.) Es ist nicht perfekt, aber es könnte viel schlimmer sein (vgl. MS Windows, wo Sie bestenfalls einen Fehlercode für Google erhalten.)

— Peter Cordes

Spielte nur mit chattr +iund bemerkte, dass rm foo(ohne -f) Eingabeaufforderungen : rm: remove write-protected regular file ‘foo’. Weil faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX muss rmstandardmäßig aufgefordert werden, bevor schreibgeschützte Dateien entfernt werden. Aus diesem Grund wird es zuerst überprüft. Sie hätten also schneller einen großen Hinweis bekommen, wenn Sie nicht verwendet hätten rm -f. : / access(3)fordert den Kernel auf, die Berechtigungen so zu überprüfen, als ob er wirklich zum Schreiben geöffnet wäre, sodass ACLs und Attribute erfasst werden.

— Peter Cordes