Ist "chown user: user lost + found" schädlich?


10

Kürzlich habe ich ein verschlüsseltes Dateisystem ( crypto_LUKS) erstellt, das nur für einen bestimmten Benutzer als $ HOME dient (dh ich mounte es als /home/pduck). Ich habe auch einen entsprechenden Eintrag hinzugefügt, /etc/security/pam_mount.conf.xmldamit die Partition automatisch entschlüsselt und gemountet wird, wenn sich der Benutzer anmeldet (und abgemeldet wird, wenn er sich abmeldet). Funktioniert super.

Da $ HOME ein eigenständiges Dateisystem ist, verfügt der Benutzer über ein lost+foundVerzeichnis von root: root. Ich weiß, dass das Löschen des Verzeichnisses eine schlechte Idee ist, aber viele Befehle (z. B. find) beschweren sich darüber, keinen Zugriff zu haben. Das nervt mich.

Aus Neugier habe ich das Verzeichnis entfernt und mit mklost+found(ohne sudo) neu erstellt. Jetzt gehört das Verzeichnis pduck: pduck. Ist das in Ordnung oder ist es entscheidend, dass das Verzeichnis root: root gehört?


Nicht alle Dateisysteme haben ein Fundbüro. Ext4 zum Beispiel, XFS nicht.
Jornane

Keine Antwort, aber Sie können einfach ein Skript oder einen Alias ​​für die Suche erstellen (vorzugsweise mit einem anderen Namen), der mit einem beginnt, 2>/dev/nullder diese Fehlermeldungen zum Schweigen bringt. Wenn Sie es am Anfang setzen, stört es nicht die Argumente, die Sie bei jedem Aufruf übergeben möchten.
Joe

Antworten:


11

Guter Rat kommt mit einer Begründung, damit Sie erkennen können, wann es zu einem schlechten Rat wird.

Der Zweck lost+found, im Besitz von root zu sein, besteht darin, dass unabhängig davon, welche Datei verloren gegangen ist, sie nicht plötzlich allen zugänglich gemacht wird. In diesem Fall sollte es jedoch keine einzige Datei im gesamten Dateisystem * geben, die nicht pduck gehört. Daher gibt es keinen Nachteil, lost+foundnicht im Besitz von Pduck zu sein.

* Ausgenommen exotische Situationen wie das Pducken suzum Rooten und Ausführen einer X-Anwendung. Aber wenn pduck verwenden kann sudooder sudann sprechen wir über nichts, weil pduck die Systemsicherheit direkt verletzen kann.


6

lost+found ist ein Systemverzeichnis, und ich vermeide Manipulationen am Besitz und den Berechtigungen von Systemverzeichnissen und -dateien.

Es gibt andere Verzeichnisse (und Dateien), die sich findbeschweren, es sei denn, ich erhöhe die Berechtigungen der Befehlszeile, daher schlage ich vor, dass Sie verwenden

sudo find ...

und so lassen, lost+foundwie es ist.


2
Ja, dachte ich, aber OTOH gibt es diesen mklost+foundBefehl, um es zu erstellen, und es erstellt es mit meinem Besitz. Vielleicht ist es nur ein schrecklich geschriebener Befehl, der nicht überprüft wird $UID!=0;-) Außerdem mag ich die Idee nicht, gezwungen zu werden (mehr oder weniger), ihn sudoin meinem eigenen $ HOME zu verwenden.
PerlDuck

lost+foundist sehr alt, denke ich aus frühen UNIX-Tagen, und ich weiß nicht wirklich, wann es heutzutage verwendet wird. Ich denke jedoch, dass es eine gute allgemeine Richtlinie ist, Manipulationen am Besitz und an den Berechtigungen von Systemverzeichnissen und -dateien zu vermeiden (es sei denn, Sie wissen wirklich, was hinter den Kulissen passieren kann).
Sudodus

5
Werden dort keine fsckDateien abgelegt, wenn auf "verlorene" Dateien gestoßen wird? Die Idee ist, dass es fsckbereits einen Platz gibt, an dem die Dateien abgelegt werden können (anstatt zuerst eine zu erstellen). Beachten Sie, dass lost+foundmehr Speicherplatz (16384 Byte) belegt ist als ein normales leeres Verzeichnis (4096 Byte).
PerlDuck

Ja, zumindest war das der ursprüngliche Zweck (ähnlich chkdskwie bei verlorenen Dateien in MSDOS), aber ich habe dort selten oder nie Daten unter Linux gesehen. Möglicherweise kann das Journaling die Dateien dort wiederherstellen, wo sie zuvor waren, sodass sie nicht aufgerufen werden müssen lost+found. - Ich habe übrigens ein lost+foundVerzeichnis in /home, aber nicht in meinem Home-Verzeichnis /home/sudodus, so dass es mich dort nicht stört.
Sudodus

1
Genau. Und in habe /homeich eine andere l+f(stört mich auch nicht), weil /homeund /home/pducksind separate Partitionen auf meinem Computer. Letzteres ist verschlüsselt, Ersteres nicht. Wenn es mich jedoch zu sehr nervt, kann ich mein $ HOME an einer anderen Stelle mounten und es an mein tatsächliches $ HOME binden (wie ich hier zum Beispiel beschrieben habe), um es l+fin meinem $ HOME vollständig loszuwerden . /// Ich werde meine Kommentare in ein paar Minuten / Stunden löschen, um die Warnung "Erweiterte Diskussion ... zum Chat wechseln" zu vermeiden .
PerlDuck

4

Das Fundbüro ist nicht wirklich magisch. Es ist nur ein einfaches Verzeichnis wie jedes andere und wird nur verwendet, um verlorene Dateien / Verzeichnisse zu speichern, die während eines fsck nach einem Systemabsturz oder einer Beschädigung des Dateisystems gefunden wurden.

Es wird während mkfs erstellt, wenn das Dateisystem erstellt wird und normalerweise leer ist. Der einzige Grund für die Standardberechtigungen besteht darin, zu verhindern, dass vertrauliche Dateien für normale Benutzer sichtbar werden, wenn sie während eines fsck gefunden und wiederhergestellt werden. In der heutigen Zeit kommt es selten vor, dass Dateien verloren gehen und in diesen Ordner verschoben werden.

Wenn es entfernt wird, wird es meiner Meinung nach von fsck nach Bedarf neu erstellt, wenn Dateien vorhanden sind, die dort abgelegt werden müssen. Da dies ein Dateisystem für einen Benutzer und seine Daten allein ist, ohne dass die Daten vor neugierigen Blicken verborgen bleiben müssen, sehe ich keinen Grund dafür, dass die Berechtigungen nicht in beispielsweise 755 geändert werden konnten, um zu verhindern, dass find sich beschwert oder ändert Eigentum. Es ist möglich, dass fsck seine Berechtigungen während eines Wiederherstellungsprozesses zurücksetzt. Dies ist jedoch ein seltenes Ereignis in einem modernen Dateisystem, es sei denn, es liegt ein schwerwiegender Hardwarefehler vor.

Ich glaube, dass all die Paranoia, die damit verbunden ist, auf der Tatsache beruht, dass es am besten ist, wenn fsck so wenig wie möglich tut, um Daten wiederherzustellen, aber ich denke nicht, dass es in der Praxis wirklich wichtig ist.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.