Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] Systembackup und [Extended] Attributes
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
kurisu
Tux's lil' helper
Tux's lil' helper


Joined: 19 Jan 2011
Posts: 85
Location: Munich, Germany

PostPosted: Wed Aug 28, 2013 4:17 am    Post subject: [solved] Systembackup und [Extended] Attributes Reply with quote

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:

Code:
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
Back to top
View user's profile Send private message
Christian99
l33t
l33t


Joined: 28 May 2009
Posts: 979

PostPosted: Wed Aug 28, 2013 6:58 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
kurisu
Tux's lil' helper
Tux's lil' helper


Joined: 19 Jan 2011
Posts: 85
Location: Munich, Germany

PostPosted: Thu Aug 29, 2013 12:50 am    Post subject: Reply with quote

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

Code:
# touch test
# setcap cap_net_raw=ep test


Der Befehl:

Code:
# getcap test


gibt erwartungsgemäß das gesetzte POSIX Capability aus:

Code:
test = cap_net_raw=ep


Eine Kopie mittels:

Code:
# 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:

Code:
# cp -a test test2
# getcap test2
test = cap_net_raw=ep


2. Immutable Flags

Code:
# touch test
# chattr +i test


Ein:

Code:
# lsattr test


gibt korrekterweise folgendes aus:

Code:
----i----------- test


Nun rsync:

Code:
# rsync -aHAX test test2
# lsattr test2
---------------- test2


Nichts. Das Flag ist verschwunden.

Selber Versuch mit cp:

Code:
# cp -a test test2
# lsattr test2
---------------- test2


Gleiches ernüchterndes Ergebnis.

3. Extended Attributes

Code:
# touch test
# setfattr -n user.eins -v zwei test


Die Anfrage:

Code:
# getfattr -n user.eins test


zeigt das erweiterte Attribut völlig korrekt:

Code:
# file: test
user.eins="zwei"


Erfreulicherweise führen hier sowohl:

Code:
# rsync -aHAX test test2


als auch:

Code:
# cp -a test test2


zum Erfolg und:

Code:
getfattr -n user.eins test2


gibt in dieser Weise jeweils:

Code:
# file: test2
user.eins="zwei"


aus.

4. PaX Flags (XATTR_PAX)

Deaktivieren von MPROTECT für Firefox:

Code:
# paxctl-ng -m /usr/bin/firefox


Überprüfen mit:

Code:
# paxctl-ng -v /usr/bin/firefox


zeigt richtigerweise nachfolgendes an:

Code:
/usr/bin/firefox:
  PT_PAX : -em--
  XATTR_PAX : -em--


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

Code:
# rsync -aHAX /usr/bin/firefox firefox


noch:

Code:
# cp -a /usr/bin/firefox firefox


zielführend, wie untenstehend unschwer zu erkennen ist:

Code:
# 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.
Back to top
View user's profile Send private message
bell
Guru
Guru


Joined: 27 Nov 2007
Posts: 418

PostPosted: Thu Aug 29, 2013 11:44 am    Post subject: Reply with quote

Hast Du schon den Rsync mit "-XX"? Lt. Manpage kopieren 2x"X" mehr als 1x"X".
Back to top
View user's profile Send private message
kurisu
Tux's lil' helper
Tux's lil' helper


Joined: 19 Jan 2011
Posts: 85
Location: Munich, Germany

PostPosted: Fri Aug 30, 2013 5:58 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
TheSmallOne
Guru
Guru


Joined: 22 Jan 2005
Posts: 451
Location: Germany

PostPosted: Tue Sep 03, 2013 12:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
kurisu
Tux's lil' helper
Tux's lil' helper


Joined: 19 Jan 2011
Posts: 85
Location: Munich, Germany

PostPosted: Tue Sep 03, 2013 9:40 pm    Post subject: Reply with quote

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ß!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum