Rechnungstore
Anmeldungsdatum: 18. Februar 2011
Beiträge: Zähle...
|
Guten Tag Zusammen. Falls "Programme" der falsche Ort für meine Frage ist, bitte verschieben. Ich wusste nicht, welcher Bereich besser passt. Ich habe von einem entfernten server per sshfs einen ordner auf meinem desktop-rechner eingebunden. Und zwar nicht als root sondern als normaler Nutzer im Folgenden einfach "nutzer" genannt. Also: | sshfs nutzer@1.2.3.4:/mnt/HC_Volume_7777777 /fusessh -o IdentityFile=/home/nutzer/.ssh/id_rsa_hetzner -p 22022 -o allow_other -C
|
Dieser Mountpunkt ist der verschlüsselte Part eine ecryptfs-mount. Also so in der fstab: | /fusessh /media/nutzer/hetzner_sshfs_storage ecryptfs noauto,user,rw,relatime,ecryptfs_fnek_sig=86e97056c4521a85,ecryptfs_sig=86e97056c4521a85,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
|
Zu Backupzwecken schiebe ich den home-ordner sowie /etc regelmäßig per rsync in den decrypted part des ecryptfs-mounts. Also so als root: | rsync -rlptvPR --delete /etc /media/nutzer/hetzner_sshfs_storage/backup_desktop_pc
|
Das klappt grundsätzlich gut. Nur eine Sache ist äußerst seltsam: Die Dateien /etc/sudoers und /etc/machine-id haben ja die Berechtigungen 440 bzw. 444. In dem Zielordner passiert jetzt folgendes (ls ebenfalls als root ausgeführt): | rumpelkiste etc # pwd
/media/nutzer/hetzner_sshfs_storage/backup_desktop_pc/etc
rumpelkiste etc # ls -l | grep sudoers
ls: Zugriff auf 'sudoers' nicht möglich: Keine Berechtigung
ls: Zugriff auf 'machine-id' nicht möglich: Keine Berechtigung
?????????? ? ? ? ? ? sudoers
|
Grundsätzlich kann ich damit leben, weil es mit anderen Dateien (die z.B. die Berechtigungen 644 oder 640 haben) nicht der Fall ist. Mich würde aber aus reiner Neugier extrem interessieren, warum das so ist. Kann das jemand erklären?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Solche Einträge können bei einem Verbindungsabbruch entstehen, aber das wirst du wohl kennen. Du musst das ganze (unabhängig vom UserMapping mit allow_other) vom Nutzer des entfernten Rechners aus sehen. Wenn dieser Zugriffsrechte für den Pfad hat, aber nicht für die Datei, dann kann stat aud die Datei nicht ausgeführt werden. Am Zielsystem kannst du den Eintrag aber anlegen, da du dort Vollzugriff hast. Es wird also eine Datei angelegt, deren Inhalt aber nicht befüllt werden kann. Das endet dann in solchen ?????-Dateien. Ist „normal“ bei sshfs. Als Beispiel:
| # auf dem entfernten Rechner
## als root
mkdir /tmp/beispiel
chmod 755 /tmp/beispiel
touch /tmp/beispiel/datei
chmod 600 /tmp/beispiel/datei
## als user
ls -lha /tmp/beispiel/
|
Du kannst zwar sehen, dass es die Datei gibt, weil du berechtigt bist das Directory auszuführen (zu betreten), aber du darfst nicht auf die Datei zugreifen, weil diese nur von root anzufassen ist. Wenn du das nun per sshfs einbindest, kannst du den Eintrag im Listing erstellen, aber an der Stelle keine Datei anzeigen, weil die Zugriffsrechte fehlen.
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Hallo ChickenLipsRfun2eat, danke für deine Antwort. So ganz leuchtet mir das aber nicht ein. Ich vermute eher, dass es irgendwie mit ecryptfs zusammenhängt. Ich erstelle auf dem Dekstoprechner zwei Dateien also root: | rumpelkiste Schreibtisch # touch testfile1
rumpelkiste Schreibtisch # touch testfile2
rumpelkiste Schreibtisch # ls -l | grep test
-rw------- 1 root root 0 Jul 28 16:19 testfile1
-r-------- 1 root root 0 Jul 28 16:20 testfile2
|
Die eine bekommt 600, die andere 400: | rumpelkiste Schreibtisch # chmod 600 testfile1
rumpelkiste Schreibtisch # chmod 400 testfile2
|
Ich schiebe sie als root auf den sshfs-mount: | rumpelkiste Schreibtisch # rsync rsync -rlptvPR --delete /home/nutzer/Schreibtisch/testfile1 /fusessh
rumpelkiste Schreibtisch # rsync rsync -rlptvPR --delete /home/nutzer/Schreibtisch/testfile2 /fusessh
|
Dann auf dem Desktoprechner: | rumpelkiste Schreibtisch # ls -l /fusessh/home/nutzer/Schreibtisch/
insgesamt 0
-rw------- 1 nutzer nutzer 0 Jul 28 16:19 testfile1
-r-------- 1 nutzer nutzer 0 Jul 28 16:20 testfile2
|
Ohne ecrypts funktioniert es also auch mit Dateien die dem root gehören und an denen niemand sonst irgendwelche Berechtigungen hat.
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Noch ne Überlegung: Grundsätzlich gilt ja, solange ich rsync als root ausführe, darf jede Datei auf dem Desktoprechner gelesen werden. Auch wenn sie nur 400 hat und root gehört. Das entfernte Verzeichnis hat auf dem Desktoprechner folgende Berechtigungen und Eigentümer: | rumpelkiste fusessh # ls -l / | grep fuse
drwxr-xr-x 1 nutzer nutzer 4096 Jul 28 16:39 fusessh
|
Demzufolge darf der root (und auch nutzer) hineinschreiben, was er möchte. So war es ja auch bei meinen beiden Testfiles eben. Sobald aber ecryptfs dazwischen hängt, kann der root offenbar keine Dateien mehr ans Ziel bringen, bei denen ihm selbst die Schreibrechte fehlen also z.B. 400 oder 440 oder 444.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Rechnungstore schrieb: Ohne ecrypts funktioniert es also auch mit Dateien die dem root gehören und an denen niemand sonst irgendwelche Berechtigungen hat.
Hast du die sudoers im ecryptfs liegen??? Guck mal mit dem Benutzer selbst, nur per ssh. Siehst du die Dateien dann korrekt? Und ja, kann gut am ecryptfs liegen, da du ja per sshfs kein elogind oder systemd-logind verwendest, der dich automagisch identifiziert.
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Hast du die sudoers im ecryptfs liegen???
Ja, alles innerhalb von /etc wird ins ecryptfs geschoben. Auch sudoers
Guck mal mit dem Benutzer selbst, nur per ssh. Siehst du die Dateien dann korrekt?
Unmöglich das zu gucken, da ecryptfs auch die Dateinamen veschlüsselt. Der Zielordner enthält eine lange Liste von Dateien mit kryptischen Namen. Gut möglich, dass die verschlüsselte sudoers darunter ist. Ich mache noch mal ein paar Tests...
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Extrem seltsam: Wenn ich jetzt als root mittels rsync die beiden Dateien direkt in den decrypted-ordner vom ecryptfs verschiebe: | rsync -rlptvPR --delete testfile1 /media/nutezr/hetzner_sshfs_storage/
rsync -rlptvPR --delete testfile1 /media/nutzer/hetzner_sshfs_storage/
|
kann ich beide sehen: | rumpelkiste Schreibtisch # ls -l /media/nutzer/hetzner_sshfs_storage | grep test
-rw------- 1 nutzer nutzer 0 Jul 28 16:19 testfile1
-r-------- 1 nutzer nutzer 0 Jul 28 16:20 testfile2
|
Wenn ich das gleiche mit der sudoers mache, dann ebenfalls: | rumpelkiste fusessh # ls -l /media/nutzer/hetzner_sshfs_storage/ | grep sudo
-r--r----- 1 nutzer nutzer 824 Mär 31 2019 sudoers
|
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Meine Theorie geht so langsam in die Richtung, dass die Dateien am Ziel schon "komplett kaputte Berechtigungen" haben und rsync das nicht ändern kann: | rumpelkiste etc # rsync -rlptvPR --delete /etc /media/nutzer/hetzner_sshfs_storage/backup_desktop_pc > /dev/null
rsync: readlink_stat("/media/nutzer/hetzner_sshfs_storage/backup_desktop_pc/etc/sudoers") failed: Permission denied (13)
rsync: readlink_stat("/media/nutzer/hetzner_sshfs_storage/backup_desktop_pc/etc/machine-id") failed: Permission denied (13)
...
|
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Keine Erklärung aber Problem immerhin gelöst: Als ich auf dem Server mittels Datei- und Ordnergrößen den /etc-Ordner gefunden habe (wie gesagt, dort sind alle Namen kryptisch und es befinden sich dort noch andere Backups), konnte ich dessen Inhalt serverseitig löschen. Nach einem erneuten rsync sind auch im Backup die Dateien machine-id und sudoers mit ihren ursprünglichen Berechtigungen vertreten.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Dann war das vielleicht mal eine fehlerhafte Synchronisation. Loggst du die rsync-Fehler mit? Müsste sich ja dann was finden. Wie erwähnt, ich kenne das von Netzwerkabbrüchen, bzw. falschen Ziel-Nutzer-Berechtigungen.
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Fehlerhafte Synchronisation könnte evtl. sein. Die rsync Fehler logge ich nicht. Ich habe auch dunkle Erinnerungen, schon mal irgendwann ein Problem mit "??????????"-Berechtigungen gehabt zu haben, das nichts mit einer Netzwerkübertragung zu tun hatte. Ich weiß aber nicht mehr, ob ich damals die Ursache oder auch nur eine Lösung gefunden habe. stackoverflow und co. gaben vorhin auf die schnelle auch nichts her, was konkret auf mein Problem gepasst hätte. Naja, hin und wieder kommt es nun mal vor, dass ich mit IT-Problemen konfrontiert werde, die ich absolut nicht verstehe 😮 . Vielleicht gewöhnt man sich irgendwann daran 😎 .
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Rechnungstore schrieb: Naja, hin und wieder kommt es nun mal vor, dass ich mit IT-Problemen konfrontiert werde, die ich absolut nicht verstehe 😮 . Vielleicht gewöhnt man sich irgendwann daran 😎 .
Ich kann mich auch daran erinnern, dass das mal vorkam. Ich hab aber auch gerade kein reproduzierbares Beispiel im Kopf, außer bei Netzwerkabbrüchen (bei denen ist aber der ganze Mountpoint ein ????). Ich nutze sshfs auch täglich, aber das hatte ich schon ewig nicht mehr.
|
Rechnungstore
(Themenstarter)
Anmeldungsdatum: 18. Februar 2011
Beiträge: 164
|
Ja, also ich vermute die Ursache in meinem konkreten Beispiel auch eher auf Dateisystemberechtigungsebene. Die Situation mit dem gesamten Mounpoint ????? hatte ich auch schon mal. Ich glaube aber damals nicht mit sshfs sondern mit nfs oder smb.
|