OpenBCM V1.07b6_bn2 (Linux)

Packet Radio Mailbox

NB1BKM

[Box OBB]

 Login: IN1BKM





  
AS1GBF > LINUX    20.02.06 01:35l 73 Lines 3735 Bytes #999 (0) @ DEU
BID : JG2AS1BOX_1D
Read: RN1NMB BL1AIB ES1MBL ES1FAI IN1BKM DAF999
Subj: Re^3:H:Partition ändern
Path: NB1BKM<AS1BOX
Sent: 060219/2304z @:AS1BOX.#NDB.BAY.DEU.BCMNET [LA JN68CQ] obcm1.05_bn4
From: AS1GBF @ AS1BOX.#NDB.BAY.DEU.BCMNET (Andreas)
To:   LINUX @ DEU
X-Info: Sent with login password

Hallo Jan,

>From: DNS205 @ DBX531.#MISA.O.DLNET.DEU.EU (Jan)
>To:   LINUX @ DEU
>X-Info: No login password
>
>Hallo Sascha und Andreas,
>
>Danke für eure Hinweise, ich habe mich rangesetzt und mit cfdisk sowie
>mke2fs das Problem gelöst.
>Derzeit habe ich die Partition auf ein Unterverzeichnis von /home gemountet, 
>um gewisse Arbeitsdaten auf unterschiedlichen Partitionen halten zu können. 
>Bißchen umständlich fand ich es, den Besitz des Verzeichnisses (nach dem 
>Mounten root) und des speziellen Unterverzeichnisses lost+found erst auf 
>meinen Standardnutzer (KEIN root, hi) ändrn zu müssen.

ja so ist das bei einem richtigen Multiuser-Betriebssystem, man muss sich
Gedanken um die Rechte der einzelnen Ressourcen und Nutzer machen. Dafür wird
man dann mit einer höheren Sicherheit belohnt.

>Ich habe derzeit die 
>Befürchtung, lost+found funktioniere damit nicht mehr korrekt, wie kann man 
>das nachprüfen? Oder muss lost+found auch auf dieser Partition root gehören?
>Mich irritiert dabei, das es eigentlich nur ein lost+found im 
>root-Verzeichnis gibt bzw. bisher gab, jetzt ist das lost+found in dem 
>Verzeichnis dazu gekommen, auf das ich /dev/hda1 gemountet habe...

Das lost+found-Verzeichnis gibt es bei bestimmten Filesystemen wie ext2 und
ext3 immer im Hauptverzeichnis des Filesystems. Das Hauptverzeichnis des
Filesystems auf /dev/hda1 ist dort, wo dessen Mountpoint ist, also irgendwo
unterhalb deines Homeverzeichnisses.

lost+found ist ein reservierter Bereich für verloren gegangene Dateien und
Verzeichnisse. Stellt fsck beim Überprüfen eines Dateisystems Fehler fest, legt
es die dem Fehler noch nicht vollständig zum Opfer gefallenen Dateien und
Verzeichnisse dort ab.

Um nicht im Fehlerfall das lost+found-Verzeichnis erst anlegen zu müssen und
durch das Anlagen Daten zu überschrieben, die eigentlich gerettet werden
sollten, wird das lost+found-Verzeichnis bereits beim Erstellen des Filesystems
angelegt.

Die Rechte des lost+found-Verzeichnisses sollten beim Rettungsvorgang durch
fsck keine Rolle spielen. Allerdings kann das lost+found-Verzeichnis nach einem
erfolgreichen Rettungsvorgang sensible Daten enthalten, auf die zuvor nur Root
Zugriff hatte. lost+found für jemand anderen als Root zugänglich zu machen
birgt also die Gefahr in sich, dass derjenige plötzlich auf Dateien zugreifen
kann, auf die er vor dem Filesystemfehler nicht zugreifen konnte, die also
höchstwahrscheinlich nicht für seine Augen bestimmt sind.

In deinem Anwendungsfall dürfte das kein Problem darstellen, weil ja auf das
Filesystem ohnehin nur besagter User Dateien ablegt. Aber an dem Beispiel sieht
man recht gut, was man bei einem Multiusersystem besonders wenn mehrere User
darauf arbeiten sollen, beachten muss.

Achja, noch eine Anmerkung weil dir wie vielen anderen jetzt sicherlich gerade
etwas wie "bei mir ist das ja ohnehin kein Multiusersystem, weil ich alleine
darauf arbeite und das ganze komplizierte Sicherheitszeugs für mich deshalb
nicht relevant ist" durch den Kopf geht: Es ist in dem Moment ein potenzielles
Multiusersystem, in dem auch nur ein Dienst von extern erreichbar ist. Das
braucht nur eine Mailbox, ein Node oder ein Webserver sein. Denn diese Dienste
können Fehler haben die jemand ausnutzt und schon hat derjenige einen
Useraccount auf deinem Rechner. Ist er erstmal auf dem System bringt ihn jede
kleine Nachlässigkeit einen Schritt weiter, um das System zu übernehmen.

Weihnachten und Ostern zugleich ist für den Einbrecher übrigens dann, wenn der
Dienst den er gehackt hat als Root lief. Dann hat er nämlich mit einem Streich
gleich einen Root-Account...

73 de Andreas 


Lese vorherige Mail | Lese naechste Mail


 03.05.2024 12:29:06lZurueck Nach oben