Base-Split-DB: Datenbankdateien vor Löschen schützen per NTFS

[Freischreiber]

Hallo,

für alle anderen Paranoiker außer mir stelle ich hier eine einfache Methode vor, wie man unter Windows bei einem NTFS-formatierten Laufwerk die wichtigsten Datenbankdateien einer gesplitteten DB vor versehentlichem Löschen schützen kann. Wie der Schutz sich bei einer eingebetteten DB verhält (nur dbname.odb), habe ich nicht ausprobiert. Die Methode ersetzt natürlich keine Sicherheitskopien, kann aber Ärger ersparen.

Bitte: erst an einer DB-Kopie ausprobieren. Nur ausprobieren, wenn der Windows-Papierkorb aktiv ist. Nicht daß beim probeweisen Löschen wichtige Dateien im Nirvana verschwinden...

Ausgangssituation: Die Datenbankdateien befinden sich in einem eigenen Unterordner "Datenbank" irgendwo unter Windows.

Ziel: Die Dateien dbname.data, dbname.odb und hsqldb.jar vor versehentlichem Löschen schützen.

Kein Ziel: die dbname.properties und dbname.script werden offenbar durch Löschen und Neuschreiben benutzt, da funktioniert dieser Schutz nicht. Wie man die schützen kann, weiß ich nicht...

Problem: Im selben Ordner liegen, entstehen während des Betriebs und werden wieder gelöscht beim Schließen der DB auch andere Dateien, wie zB die dbname.lck und die dbname.log. Daher verbietet sich ein Löschschutz für das ganze Verzeichnis. Diese Dateien brauchen den Löschschutz auch nicht, da sie, solange sie existieren, von Base bzw. der DB geöffnet sind und von Windows geschützt werden.

Lösung:

0. Sicherstellen, daß der angemeldete Benutzer der Besitzer des Ordners und der Dateien ist.
Eigenschaften - Sicherheit - Erweitert - Besitzer

1. Der Unterordner "Datenbank" bekommt die vererbten Rechte weggenommen, die sonst nur für Verwirrung sorgen. Einträge für Administratoren oder System sind unnötig. Je nach Wunsch können die folgenden Rechte für "Jeder", "Authentifizierte Benutzer" oder nur den konkreten Benutzer eingeräumt werden.

Eigenschaften - Sicherheit - Erweitert - Berechtigungen ändern: Häkchen raus bei "Vererbbare Berechtigungen ... einschließen".
Die folgende Frage mit "Entfernen" beantworten.

vererbbare-berechtigungen-löschen.png (6.09 KiB) 3048 mal betrachtet

2. Für "Jeder" einen neuen Berechtigungseintrag erstellen.
Eigenschaften - Sicherheit - Bearbeiten - Hinzufügen: Jeder.
Dann in der "Zulassen"-Spalte "Ändern" anklicken. Es entstehen fünf Häkchen.
OK drücken.

ordnerrechte-datenbank.png (7.09 KiB) 3048 mal betrachtet

3. Für die Dateien dbname.data, dbname.odb und hsqldb.jar jeweils einzeln einen Verweigerungseintrag setzen.
Eigenschaften - Sicherheit - Erweitert - Berechtigungen ändern - Hinzufügen: "Jeder".
Dann in der "Verweigern"-Spalte ein Häkchen setzen bei "Löschen".
OK drücken. Kontextmenü schließen.

verweigerungseintrag-einzeldatei.png (10.07 KiB) 3048 mal betrachtet

Die drei Dateien (und der Datenbankordner selbst) sind, sobald die Verweigerungseinträge gesetzt sind, nicht mehr löschbar, aber von Base bzw. der Datenbank ganz normal beschreib- und veränderbar.

Mein Sicherheitsgefühl hat sich dadurch jedenfalls erhöht.

Gruß
Freischreiber

[gogo]

... unter Linux setzt man das Sticky-Bit für das Verzeichnis und ordnet die Dateien einem Non-login-Nutzer bzw einer Non-login-Gruppe zu :

Code: Alles auswählen

sudo chmod 1777 MeinDatenbankVerzeichnis
sudo chown nobody:nogroup MeinDatenbankVerzeichnis/* 

[Freischreiber]

@gogo:

Ja, sieht einfacher aus, bezieht sich aber auf den ganzen Ordner, was bei Windows natürlich auch einfacher einzurichten geht.
Sammeln sich da nicht temporäre Dateien und Kopien der .script- und .properties-Datei an?

[gogo]

ja, aber die gehören dem, der sie erstellt, sind also auf den aktuellen User bezogen und können von diesem jederzeit geändert und gelöscht werden...

wobei ich etwas geflunkert habe, und daher folgendes hinzufügen muss

Eine Ein-Dateien-Datenbank kann man so wie geschildert machen, eine Split-DB braucht etwas mehr, nämlich 2 zusätzliche Scripte (nicht schlimm, jeweils nur 1 Zeile) und für diese 2 Scripte sudo-Einträge (auch jeweils eine Zeile). Der Grund liegt darin, dass die "properties", die "backup" und die "script" Datei nicht beschrieben, sondern nach dem Schließen der DB durch die Dateien properties.new, backup.new und script.new ersetzt werden, und das ist unter UNIX natürlich nicht möglich, denn die 2 Dateien sind ja löschgeschützt und können daher nicht gegen andere ausgetauscht werden.
Anders als bei NTFS-Systemen haben die unixoide Dateisysteme (ext...) einzigartige Inodes. D.h. eine Datei wird nicht über den Dateinamen, das Verzeichnis oder Ähnliches definiert, sondern nur über die inode-#. Man kann eine Datei also nicht einfach austauschen wie unter FAT oder NTFS, weil die inode-# als Entität fungiert. Das ist das zentrale Sicherheitsmerkmal von UNIX-Systemen, welches all das gar nicht zulässt was mich vor 2008 Nerven gekostet hat

[Freischreiber]

Also gibt es unter Linux für die .properties- und .script-Datei eine Berechtigungseinstellung, die sie vor Löschen schützt und trotzdem überschreibbar läßt? Oder gerade nicht?

Wenn ja, würden mich Details interessieren. Denn die Rechtestufen von Ext4 usw. kann man offenbar auf NTFS-Rechte abbilden, nur umgekehrt nicht...

Wie gesagt, wenn diese beiden Dateien nicht wären, würde ich unter Windows auch mit einfacheren Einstellungen auskommen (Ändern-Rechte für den Ordner ohne "Löschen", keine Verweigerungen nötig).

Gruß
Freischreiber

[gogo]

...die Rechtestufen von Ext4 usw. kann man offenbar auf NTFS-Rechte abbilden, nur umgekehrt nicht...

NTFS hat einen Haufen Sonderrechte, bei denen ich den Sinn oft nicht nachvollziehen kann, aber der NTFS-3G Treiber der meist für's Einbinden benutzt wird kann so weit ich weiß UNIX-Dateirechte (auch acl) auf NTFS-Laufwerken(edit: "Systemen" durch "Laufwerken" ersetzt) zumindest simulieren.
Wie man ext4 in Windows einbindet kann ich Dir nicht sagen, das Wiki von ubuntuusers.de ist aber sicher eine gute Quelle.

Für eine 1-Dateien-Datenbank reicht es unter Linux auf das Verzeichnis das sticky-bit zu setzen, (das ist der "1"er in chmod 1777). Das sticky-bit bewirkt, dass in einem Verzeichnis eine Datei nur vom Eigentümer gelöscht werden kann. Die Rechte 777 bedeuten, dass alle anderen user volle Rechte auf dem Verzeichnis haben, sie können also lesen, schreiben und ausführen. Um zu verhindern dass die Datei gelöscht wird muss als Eigentümer der Datei irgendjemand herhalten, den's nicht gibt (nobody) - d.h. nur nobody (und klarerweise root) könnten die Datei löschen.

Eine 1-Dateien-Datenbank würde ich also in so ein Verzeichnis kopieren und dann als Eigentümer "nobody" angeben und als Eigentümergruppe z.B. die Gruppe "db_benutzer" (chown nobody:db_benutzer Datei.odb), das Verzeichnis kann man dann mit den Rechten chmod 1770 (oder 1660) ausstatten und schon haben alle user die der Gruppe db_benutzer angehören die Möglichkeit die Datei zu bearbeiten, aber nur nobody könnte sie löschen.

Eine Split-Datenbank ist auch möglich, wie schon gesagt mit ein paar Kniffen - kurz gefasst: die Datenbank-Dateien müssen irgendeinem User gehören der sich normalerweise nicht einloggt (db_user, Passwort nur dem Admin bekannt). Die Leute die dann mit der Datenbank arbeiten müssen die Datenbank unter dem Namen "db_user" öffnen. Dafür gibt es auf Linux-Systemen den Befehl sudo. Meist wird er dafür genutzt etwas als "root" auszuführen, aber mit sudo -u db_user libreoffice /var/DB/MeineDatenbank.odb macht man das eben als "db_user".

... aber bevor ich das machen würde, setz' ich lieber einen HSQLDB-Server auf, das geht auch ganz flott und man hat all den Komfort den ein Server bietet. "Besser dokumentiert" und mit mehr How-To-Do's im Netz wären die Platzhirschen MySQL und Postgree.

oh - einen Tipp hätt' ich noch: Wenn Du Deine Datenbank als Datenquelle in LO registriert, kannst Du die Formulare der *.odb auslagern und als Writer-Dokumente irgendwo abspeichern. Die Daten des Formulars holt das Writer-Dokument dann aus der odb die weiss-Gott-wo liegt.

[Freischreiber]

Hallo gogo,

das DB-Verzeichnis einem anderen Benutzer als Besitzer "geben" und dann "Ausführen als..." zum Starten der Datenbank ist eine Idee, die auch unter Windows funktionieren müßte... werde ich mal ausprobieren, wenn ich den Nerv dazu habe.

Einen HSQLDB-Server, dazu bräuchte ich noch viel mehr Nerven... und auch da wird man die Dateien ja auf der Festplatte irgendwie schützen wollen/müssen? (also bei mir jedenfalls, weil ich nur an einem Arbeitsplatz mit der DB arbeite).

Danke und Gruß
Freischreiber

[gogo]

Sichern gegen unbeabsichtigte Veränderun beduetet den unbeabsichtigten Zugriff auf die Datei zu verhindern. So etwas erledigt ein Datenbankserver für Dich. Er macht genau das was wir oben besprochen haben, d.h. er verunmöglicht den Zugriff auf die Datendateien und regelt durch "Anmeldung" den Zugriff durch Software (Treiber) auf die Dateninhalte.

Sichern gegen Datenverlust bedeutet mindestens eine Datenkopie auf einem anderen Gerät (anderer Stromkreis!) zu haben. Die Datenkopie muss keine exakte Kopie sein. Im Normalfall wird diese Kopie als Export von Daten in einer anderen elektronischen Form (idealerweise normiert) gemacht. Aus den Datendateien im z.B. Binär-Format das der ServerA lesen kann wird dann z.B. ein Text-File in dem SQL-Statements stehen die die Tabelle wiederherstellen können. SQL ist - so weit ich weiß - seit '87 genormt, es ist also anzunehmen, dass die meisten Datenbanksysteme damit was anfangen können. Wenn man den ServerA z.B. in der alten u.U. zerstörten Softwareversion nicht mehr bekommt, kann man also auf ein anders System umziehen ... mit all seinen Daten.

Wer nur gelegentlich seine Daten bearbeitet, braucht einfach nur 'ne Kopie irgendwo - das reicht meist, da der Schaden durch unbeabsichtigtes "Vernichten" in der Regel schnell kompensiert werden kann. Die Regelmäßigkeit der Sicherheitskopie (erledigt am besten eine Software) und ihre Verwendbarkeit (muss man selber machen) müssen aber geprüft werden! Am besten ist es sich das in den Kalender zu schreiben - also: Sicherungssystem ausdenken > System einführen und zum Laufen bringen > am Tag danach prüfen > 1 Woche später prüfen > x Monate später prüfen etc. Je nach Wichtigkeit.