# [solved] Systembackup und [Extended] Attributes

## kurisu

Neben den obligatorischen Datenbackups fahre ich seit längerem auch regelmäßig inkrementelle Backups meiner Root-Partitionen (i.e. das komplette Wurzelverzeichnis inkl. /var, /usr usw., jedoch exkl. /boot, /home oder anderenorts eingehängter Datenpartitionen). Dazu verwende ich rsync via sysresccd mit nachfolgendem Befehl:

```
rsync -aHAX --delete [source] [destination]
```

Soweit klappt das auch wunderbar. Jedoch musste ich nun feststellen, dass dabei weder POSIX Capabilities noch PaX Flags (XATTR_PAX) übernommen werden. Woran liegt das? Mittels Parameter X weise ich rsync doch explizit an, Extended Attributes zu berücksichtigen. Meine bisherigen Recherchen haben mich u.a. hierhin geführt. Aber auch cp -a bringt entgegen der Aussagen im verlinkten Thread keinerlei Besserung. Mache ich irgendetwas grundlegend falsch?

Halbwegs zu verschmerzen wäre dies auf meinem normalen System, da es hier nur um eine Hand voll Dateien geht, die leicht manuell nachjustiert werden können. Ernsthafte Kopfschmerzen bereitet mir hingegen mein Hardened-System, das im Backup-Fall angesichts unzähliger zerschossener PaX Flags kaum mehr funktional wäre. Das kann es doch echt nicht sein.

Falls jemand eine Idee oder Anregung dazu hat, bitte her damit. Besten Dank im Voraus.Last edited by kurisu on Fri Sep 06, 2013 10:57 pm; edited 3 times in total

----------

## Christian99

Ich hab nicht wirklich Ahnung davon, aber so als idee:

vielleicht hat das rsync deiner sysresccd keine Unterstützung für extended attributes. unter gentoo lässt sich das nämlich mittels useflag an und abschalten.

Vielleicht kannst du das mal mit deinem gentoo rsync ausprobieren und schauen ob es da geht oder nicht

----------

## kurisu

Vielen Dank für den Tipp. Diesen Gedanken hatte ich auch schon. Im Resultat ist zu sagen, dass sysresccd erwartungsgemäß natürlich ein mit USE="xattr" gebautes rsync aufweist. Hier liegt das Problem also nicht. Die Sache scheint offenbar weitaus komplexer.

Denn wie etwa auch hier in aller Knappheit nachzulesen ist, werden Dateiattribute offenbar uneinheitlich behandelt. Da meine Recherchen insgesamt aber mehr widersprüchlich als hilfreich verlaufen sind, habe ich ein paar Beispiele für mich durchexerziert, um mehr Klarheit zu erlangen. Im Folgenden schreibe ich das einfach mal zusammenfassend nieder. Vielleicht interessiert es ja jemanden.

Update: Ergänzend sei darauf hingewiesen, dass sämtliche Dateioperationen und -manipulationen auf einem ext4-Dateisystem vollzogen wurden, das mit -o defaults,noatime gemounted wurde. Das USE Flag "xattr" ist global gesetzt. Unterstützung für xattr ist laut man mount bei ext4 immer gegeben.

1. POSIX Capabilities

```
# touch test

# setcap cap_net_raw=ep test
```

Der Befehl:

```
# getcap test
```

gibt erwartungsgemäß das gesetzte POSIX Capability aus:

```
test = cap_net_raw=ep
```

Eine Kopie mittels:

```
# rsync -aHAX test test2

# getcap test2
```

liefert hingegen gar keine Ausgabe. Das POSIX Capability ist demnach weg.

Interessanterweise führt ein Versuch mit cp allerdings zum Ziel:

```
# cp -a test test2

# getcap test2

test = cap_net_raw=ep
```

2. Immutable Flags

```
# touch test

# chattr +i test﻿
```

Ein:

```
# lsattr test
```

gibt korrekterweise folgendes aus:

```
----i----------- test
```

Nun rsync:

```
# rsync -aHAX test test2

# lsattr test2

---------------- test2
```

Nichts. Das Flag ist verschwunden.

Selber Versuch mit cp:

```
# cp -a test test2

# lsattr test2

---------------- test2
```

Gleiches ernüchterndes Ergebnis.

3. Extended Attributes

```
# touch﻿ test

# setfattr -n user.eins -v zwei test
```

Die Anfrage:

```
# ﻿getfattr -n user.eins test
```

zeigt das erweiterte Attribut völlig korrekt:

```
# file: test

user.eins="zwei"
```

Erfreulicherweise führen hier sowohl:

```
# rsync -aHAX test test2
```

als auch:

```
# cp -a test test2
```

zum Erfolg und:

```
getfattr -n user.eins test2
```

gibt in dieser Weise jeweils:

```
# file: test2

user.eins="zwei"
```

aus.

4. PaX Flags (XATTR_PAX)

Deaktivieren von MPROTECT für Firefox:

```
# paxctl-ng -m /usr/bin/firefox
```

Überprüfen mit:

```
# ﻿paxctl-ng -v /usr/bin/firefox
```

zeigt richtigerweise nachfolgendes an:

```
﻿/usr/bin/firefox: 

  PT_PAX : -em-- 

  XATTR_PAX : -em-- 
```

Obwohl es wie in Beispiel 3 auch hier um erweiterte Attribute geht, ist kurioserweise weder:

```
# rsync -aHAX /usr/bin/firefox firefox
```

noch:

```
# cp -a /usr/bin/firefox firefox
```

zielführend, wie untenstehend unschwer zu erkennen ist:

```
# ﻿paxctl-ng -v firefox

firefox: 

  PT_PAX : -E--- 

  XATTR_PAX : not found
```

Fazit

Angesichts der für mich nur minder nachvollziehbaren Ursachen, weswegen die Sicherung abhängig von der Art des Dateiattributes das eine Mal funktioniert, das andere Mal hingegen nicht, werde ich es der Einfachheit halber zukünftig wie folgt halten: (1) System weiterhin mit rsync sichern, da ein zügiges und damit vorzugsweise inkrementelles Systembackup stark erwünscht ist, wenngleich dd potentiell eine Lösung wäre; (2) für meine beiden Systeme individuell angepasste Scripte schreiben, die mir die kritischen Dateiattribute im Backup-Fall wiederherstellen; (3) dies als Prämisse genügt fortan ein simples rsync -a.

Damit markiere ich den Thread mal als solved. Ideen oder Anregungen sind jedoch weiterhin gerne gesehen.

----------

## bell

Hast Du schon den Rsync mit "-XX"? Lt. Manpage kopieren 2x"X" mehr als 1x"X".

----------

## kurisu

Diese Option kannte ich noch nicht. Damit bleiben die PaX Flags beim Kopieren von betreffenden Dateien auf meinem Hardened-System tatsächlich erhalten. Offenbar werden nun also alle Extended Attributes von rsync berücksichtigt. Klasse! Einzig POSIX Capabilities und Spezialfälle wie das Immutable Flag müssten im Backup-Fall nun noch manuell gesetzt werden. Das ist aber nicht weiter schlimm, da solche Dateien auf beiden Systemen ohnehin kaum vertreten sind. Wichtig sind vor allem die zu Dutzenden gesetzen PaX Flags, ohne die mein Hardened-System kaum funktional wäre. Danke für den Tipp.

----------

## TheSmallOne

Lässt du deinen Prozess als Root laufen, oder als User?

Laut manpage kann nur Root das Flag überhaupt setzen.

Aber davon abgesehen: Wie genau stellst du dir das Verhalten bei deinem Backup denn eigentlich vor? Das Flag soll ja dazu da sein, Änderungen an einer Datei komplett zu verbieten. Was sollte rsync denn deiner Meinung nach tun, wenn es beim inkrementellen Backup plötzlich eine Datei vorfindet, die das immutable flag gesetzt hat? Speziell wenn diese das auch im Zielverzeichnis besitzt. Das Flag verbietet ja schließlich jegliche Änderung.

----------

## kurisu

Der Prozess wird stets als root in einer Live-Umgebung (sysresccd) ausgeführt. Das ist auch unbedingt erforderlich, um rsync wirklich alle Dateien berücksichtigen zu lassen.

Hinsichtlich des Immutable Flags hast Du vollkommen recht. Nachdem ja gerade das Unterbinden jedweder Dateimanipulationen – das Überschreiben und Löschen mit inbegriffen – Zweck des Flags ist, sind Bestrebungen dieses bei der inkrementellen Datensicherung mit einzubeziehen – zumindest langfristig betrachtet – absurd. Immerhin ist nicht auszuschließen, dass eine Datei, hinsichtlich derer keinerlei Änderungsabsicht besteht und zur Unterstreichung des Ganzen daher explizit das Flag gesetzt wird, wider Erwarten irgendwann doch geändert wird. Sofern auf dem Zielverzeichnis die alte Version mitsamt Immutable Flag liegt, stieße rsync in diesem Fall natürlich auf ein Problem. So gesehen macht es durchaus Sinn, dass sowohl rsync als auch cp das Flag ignorieren. Offenkundig hatte ich hier nicht zu Ende gedacht. Da meine beiden Systeme aber jeweils genau eine derartig manipulierte Datei aufweisen, ist der infolge des dadurch nötigen manuellen Eingriffes anfallende Mehraufwand ohnehin nicht der Rede wert. Besten Dank für den Gedankenanstoß!

----------

