☰

Wie testet man nicht-invasiv den Schreibzugriff auf eine Datei?

tag-icon • tag-icon shell-script files permissions scripting
Wie testet man nicht-invasiv den Schreibzugriff auf eine Datei?

Wie kann ich in einem Shell-Skript einfach undnicht-invasivSchreibzugriff auf eine Datei testen, ohne tatsächlich zu versuchen, die Datei zu ändern?

Ich könnte die Ausgabe von analysieren stat, aber das scheint wirklich komplex und möglicherweise fehlerhaft zu sein, obwohl ich nicht sicher bin, wie sehr sich die Statistikausgabe zwischen Implementierungen und im Laufe der Zeit unterscheidet.

Ich könnte es an das Ende der Datei anhängen und sehen, ob das klappt, aber das ist aus zwei Gründen, die mir einfallen, potenziell gefährlich:

  1. Ich muss den Zusatz nun wieder entfernen und für den Fall, dass ein anderer Prozess in die Datei schreibt, ist das sofort nicht mehr trivial, da meine Zeile nicht mehr die letzte ist.
  2. Jeder Prozess, der die Datei liest, kann beliebige Anforderungen an den Inhalt dieser Datei stellen, und ich habe diese Anwendung möglicherweise gerade beschädigt.

Antwort1

Benutzen Sie einfach die - wFlagge dertestDienstprogramm:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Beachten Sie, dass es immer noch möglich ist, dass Sie nicht in die Datei schreiben können, wenn Sie sie später erneut schreiben möchten. Die Datei wurde möglicherweise verschoben, die Berechtigungen haben sich geändert usw. Es kann auch passieren, dass-werkennt Schreibberechtigungen, aber ein anderer Faktor greift ein und macht die Datei nicht beschreibbar.

Antwort2

Ein anderer Ansatz:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Dadurch wird versucht, die Datei zum Anhängen zu öffnen. Wenn dies gelingt, laufenkein Kommentar(dh,Führen Sie einen Nullbefehl aus) mit Ausgabe in die Datei. 

Beachten Sie, dass dadurch eine leere Datei erstellt wird, wenn sie nicht vorhanden ist.

Der -wOperator des testBefehls führt möglicherweise einfach ein aus stat und versucht dann herauszufinden, ob es so aussieht, als ob Sie Zugriff haben sollten. Meine Alternative (oben) ist testunter bestimmten Umständen zuverlässiger als der Ansatz, da sie die Zugriffsprüfung vom Kernel und nicht von der Shell durchführen lässt. Beispiel:

  • wenn sich die Datei auf einem Nicht-Unix-Dateisystem befindet – insbesondere, wenn sie von einem Nicht-Unix-Dateiserver remote gemountet wird –, weil statmöglicherweise ein Moduswert zurückgegeben wird, der irreführend ist.
  • wenn sich die Datei auf einem Dateisystem befindet, das schreibgeschützt gemountet ist.
  • wenn die Datei über eine ACL verfügt und der Modus den Anschein erweckt, als ob Sie Zugriff haben sollten, die ACL diesen jedoch verweigert, oder umgekehrt.
  • wenn ein Sicherheitsframework (AppArmor, SELinux, …) den Zugriff auf die Datei verweigert.

Antwort3

G-man hat recht: [ -w ]wird nichtstetsdie Wahrheit sagen. Hier mit nicht vorhandenen Datei zu bewältigen undZugriff verweigertNachricht von der Shell:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Aktualisieren: Sieht beängstigend aus, nicht wahr? Nun, das ist es. Hmm... wie soll ich es ausdrücken... VERWENDEN SIE DIES NICHT, es sei denn, Sie wissen genau, dass Sie sich in den erforderlichen Bedingungen befinden, um wie erwartet zu funktionieren. Siehe Stephanes Kommentar.

Was ist also zu folgern? Auch wenn [ -w ]es nicht die Wahrheit sagt, ist es das einzige Gebot, dasbeabsichtigtum die Arbeit zu erledigen. Wenn es das nicht tut, nun, dann geben wir ihm die Schuld, schreiben Fehlerberichte und es wird in Zukunft funktionieren. Überprüfen Sie besser die Bedingungen, unter denen es funktioniert und verwenden Sie [ -w ]; schreiben Sie speziellen Code für spezielle Fälle. Workarounds haben ihre eigenen Bedingungen.

[ -w /path/to/file ]

ist das Bestea priori.

verwandte Informationen