Auf modernen Linux-Systemen sollten Sie /proc/1/fdinfo/0 verwenden können (Informationen für den Dateideskriptor 1 (stdout) des Prozesses von ID 1 (init im Root-PID-Namespace, der als root laufen sollte )).
Eine Liste finden Sie mit (als normaler Benutzer):
sudo find /etc /dev /sys /proc -type f -print0 |
perl -l -0ne 'print unless lstat'
(-type f entfernen wenn Sie sich nicht auf normale Dateien beschränken möchten).
/var/cache/ldconfig/aux-cache ist ein weiterer potenzieller Kandidat, wenn Sie nur Ubuntu-Systeme in Betracht ziehen müssen. Es sollte auf den meisten GNU-Systemen als /var/cache/ldconfig funktionieren wird nur durch ldconfig lesbar, schreibbar und durchsuchbar für root erstellt Befehl, der mit der GNU libc geliefert wird.
Wenn Sie sich die lstat(2)-Manpage ansehen, können Sie sich zu Fällen inspirieren lassen, in denen es mit anderen Fehlern als ENOENT (Datei existiert nicht) fehlschlagen könnte.
Das offensichtlichste ist:
EACCES Die Suchberechtigung wird für eines der Verzeichnisse im Pfadpräfix von Pfad verweigert .
Sie brauchen also ein Verzeichnis, in dem Sie nicht suchen können.
Ja, Sie können nach einem suchen, das sich bereits in Ihrem System befindet (vielleicht /var/lib/private falls es existiert?) Aber Sie könnten genauso gut selbst eins erstellen, mit dem Äquivalent von:
$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile
Die lstat(2)-Operation schlägt hier mit EACCES fehl. (Das Entfernen aller Berechtigungen aus dem Verzeichnis stellt dies sicher. Vielleicht brauchen Sie nicht einmal so viel und chmod -x Das Entfernen von Ausführungsberechtigungen würde ausreichen, da Ausführungsberechtigungen für ein Verzeichnis benötigt werden, um auf Dateien darunter zuzugreifen.)
Es gibt noch einen anderen kreativen Weg, um lstat(2) zum Scheitern zu bringen, wenn man sich die Manpage ansieht:
ENOTDIR Eine Komponente des Pfadpräfixes von Pfad ist kein Verzeichnis.
Versuchen Sie also, auf eine Datei wie /etc/passwd/nonexistent zuzugreifen sollte diesen Fehler auslösen, der sich wiederum von ENOENT ("No such file or directory") unterscheidet und Ihren Anforderungen entsprechen könnte.
Eine andere ist:
ENAMETOOLONG Pfad ist zu lang.
Aber Sie brauchen vielleicht einen wirklich langen Namen für diesen (ich glaube, 4.096 Bytes sind die typische Grenze, aber Ihr System/Dateisystem könnte einen längeren haben.)
Schließlich ist es schwer zu sagen, ob einer von diesen tatsächlich sein wird nützlich für Sie. Sie sagen, Sie möchten etwas, das nicht das Szenario „Datei existiert nicht“ auslöst. Während dies normalerweise einen ENOENT-Fehler bedeutet, werden in der Praxis viele Prüfungen auf höherer Ebene einfach alle Fehler von lstat(2) als "existiert nicht" interpretieren. Zum Beispiel test -e oder das Äquivalent [ -e ...] von der Shell könnte einfach alles Obige einfach als "existiert nicht" interpretieren, zumal es keine gute Möglichkeit gibt, eine andere Fehlermeldung zurückzugeben, und die Nichtrückgabe eines Fehlers implizieren würde, dass die Datei existiert, was mit Sicherheit nicht der Fall ist der Fall.
Sie können find es selbst.
Mit /etc -- das Verzeichnis der Konfigurationsdateien als Ausgangspunkt:
sudo find /etc -type f -perm 0400 -user root
Auf meinem System gibt dies nichts zurück.
Sie können weniger restriktiv sein und die Gruppe root zulassen (nur Benutzer root sollte Mitglied der Gruppe root sein ) und achten Sie auf die Berechtigung 440 :
sudo find /etc -perm 0440 -user root -group root
Auf meinem System gibt dies zurück:
/etc/sudoers.d/README
/etc/sudoers
Bearbeiten:
Basierend auf Ihrer Bearbeitung suchen Sie nach einem Verzeichnis, das nicht über ausreichende Berechtigungen für den aufrufenden Benutzer verfügt, um die Verzeichnisauflistung zu verhindern:
sudo find / -perm o-rwx -type d -user root -group root
hier suche ich nach Verzeichnissen (-type d ), denen die Read-Write-Execute Perm-Bits für andere fehlen (o-rwx ) und gehört root:root .
Technisch gesehen ist nur das Fehlen von execute (x ) Bit würde eine Verzeichnisauflistung verhindern (lstat(2) ) im Verzeichnis.
In der Ausgabe habe ich /run/systemd/inaccessible/ gefunden auf meinem Systemd-Init-basierten System.
In Bezug auf Dateien in /proc , /sys , /dev :
-
Diese Dateisysteme sind virtuelle FS, d. h. sie befinden sich im Arbeitsspeicher, nicht auf der Festplatte
-
Wenn Sie sich auf
/procverlassen möchten , verwenden Sie/proc/1/dh verlassen Sie sich auf etwas unter PID 1, nicht auf spätere PIDs, um Zuverlässigkeit/Konsistenz zu haben, da die späteren PIDs (Prozesse) nicht garantiert existieren.