Dateisystem permanent ro mounten - möglich?

[lemak]

Hallo,

ich möchte gern ein Dateisystem permanent read-only einbinden. Also das es, nachdem es während des booten eingebunden wurde, nicht mehr möglich ist, während das System läuft mit mount -o rw,remount / das Dateisystem wieder mit Schreibrechten auszustatten.
Ist sowas möglich? Ich meine mal etwas in der Richtung gelesen zu haben, oder wars nur ein Traum? Finde tue ich nichts dazu.

MfG
lemak

PS: Es geht um das root-fs des Raspberry Pi auf der SD-Card. Siehe auch: viewtopic.php?t=141876

[pferdefreund]

den remount darf eh nur root, es sei denn, es ist in der fstab was anderes hinterlegt - und das ist auch gut so. Ansonsten könnte ja root ein irrtümlich ro gemountetes Dateisystem nicht wieder auf die Reihe kriegen. Mounten ist im Regelfall Root-Geschäft und Root sollte wissen, was er tut.

[schorsch_76]

Beim Raspi auf der SD Karte könntest du auf das Image ein aufs legen. Siehe [1] [2] [3]

Gruß
schorsch

[1] http://wiki.debian.org/ReadonlyRoot
[2] https://help.ubuntu.com/community/aufsR ... OnUsbFlash
[3] http://fengweizhang.blogspot.de/2011/01/aufs-howto.html

EDIT: Zusätzlicher Link

[cosmac]

hi,

ich möchte gern ein Dateisystem permanent read-only einbinden. Also das es, nachdem es während des booten eingebunden wurde, nicht mehr möglich ist, während das System läuft mit mount -o rw,remount / das Dateisystem wieder mit Schreibrechten auszustatten.

1.) du kannst das Device auf read-only umschalten (hier z.B. mein / auf sda2):

Code: Alles auswählen

# blockdev --setro /dev/sda2
# mount -o remount,rw /
mount: cannot remount block device /dev/sda2 read-write, is write-protected

aber natürlich lässt sich das mit "--setrw" wieder rückgängig machen -- es geht eben nichts über einen echten Hardware-Schalter. Es hilft allerdings gegen eine Besonderheit von ext3/4 (und anderen FS mit Journal?). Die schreiben nämlich u.U. auch dann, wenn man read-only mountet:

-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.

Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount ext3 or ext4 filesystem with "ro,noload" mount options or set the block device to read-only mode, see command blockdev(8).

2.) Du könntest ein Bit im "Readonly-compatible feature set"[1] im Superblock der Partition setzen, das der Kernel nicht kennt (oder einen abgespeckten Kernel bauen). Dann kann er die Partition nur noch read-only mounten.

[1] https://ext4.wiki.kernel.org/index.php/ ... uper_Block

[lemak]

2.) Du könntest ein Bit im "Readonly-compatible feature set"[1] im Superblock der Partition setzen, das der Kernel nicht kennt. Dann kann er die Partition nur noch read-only mounten.

[1] https://ext4.wiki.kernel.org/index.php/ ... uper_Block

Das hört sich interessant an. Kannst du das etwas genauer erklären? Es scheint ein einfacher Lösungsansatz, den ich gern etwas weiter verfolgen möchte.
Wie setze ich das um? Wie komme ich an den Superblock des Journal? Muss die Superblock checksum weiterin stimmen, oder macht das "Fehlerbit", also eine falsche Check-Summe gereade das erzuwungene ro aus? Wo setze ich das Bit, kann ich direkt auf der Gerätedatei arbeiten? Es ist wohl besser eine Lib zu nutzen: http://www.fifi.org/doc/e2fslibs/html-i ... s_toc.html?
Muss ich dann verhindern, das man das Bit wieder korregiert mit einem der FS-Tools einfach repariert im Betrieb. Aber RO sollte RO sein?

Edit: Okay du meinst wohl s_feature_ro_compat in ext4_super_block? Readonly-compatible feature set. If the kernel doesn't understand one of these bits, it can still mount read-only. Any of: ...

[cosmac]

Okay du meinst wohl s_feature_ro_compat in ext4_super_block?

ja, genau.

Es ist wohl besser eine Lib zu nutzen: http://www.fifi.org/doc/e2fslibs/html-i ... s_toc.html?

auf jeden Fall; noch besser wäre, mit tune2fs klar zu kommen. Ich dachte z.B. an tune2fs -O dir_nlink auf einem ext3. Wenn der Kernel nur ext3 versteht, könnte das so funktionieren und dürfte praktisch keine Auswirkung haben (wer hat schon mehr als 32000 Subdirectories?).

Muss ich dann verhindern, das man das Bit wieder korregiert (wohl auf 0 setzt) oder den Superblock mit einem der FS-Tools einfach repariert im Betrieb. Aber RO sollte RO sein?

Das scheint mir das größere Problem zu sein. Natürlich kann man es rückgängig machen, tune2fs arbeitet ja mit dem nicht-gemounteten Dateisystem. Diese RO-Geschichte greift nur in dem Moment, in dem du versuchst zu mounten. Insofern wäre blockdev --setro wirksamer, das verhindert auch den Zugriff durch tune2fs.

Aber für Updates oder Konfig-Änderungen musst du es ja rückgängig machen können...

Noch ein praktisches Problem: kannst du für den Rechner überhaupt einen Kernel bauen?

[lemak]

Achso.

Code: Alles auswählen

# blockdev --setro /dev/sda2
# mount -o remount,rw /
mount: cannot remount block device /dev/sda2 read-write, is write-protected

aber natürlich lässt sich das mit "--setrw" wieder rückgängig machen -- es geht eben nichts über einen echten Hardware-Schalter.

Hm das scheint beim RPi genau andersrum.

blockdev --setrw /dev/mmcblk0 und touch foo scheitert weiterhin.
mount -o rw,remount /dev/mmcblk0p2 und touch foo legt die datei foo an.

doof... sonst scheint das die Lösung zu sein.

Noch ein praktisches Problem: kannst du für den Rechner überhaupt einen Kernel bauen?

Ich denke schon das es möglich ist den Kernel für den Raspberry Pi anzupassen.

Aber für Updates oder Konfig-Änderungen musst du es ja rückgängig machen können...

Das Blockgerät muss entweder an einem 2. PC RO/RW gesetzt werden können od. man muss über einen Parameter am Boot-Promt Schreibrechte ermöglichen können.

[lemak]

Ich habe mir nun einen USB-Stick mit write-protection besorgt und dort das root-fs drauf. Funktioniert super.