Hallo zusammen, ich möchte von einem enfernten Rechner (Debian5) auf einen lokalen Rechner (auch Debian5) mittels ssh/rsync ein komplettes backup ziehen. Also habe ich den Benutzer backup zur root gruppe hinzugefügt um auch alles lesen zu können. Allerdings bekomme ich immer wieder fehler "Permission denied (13)" kann mir jetzt mal jemand erklären wie das zusammenhängt? der Benutzer backup müsste doch root rechte besitzen! oder nicht? Gruß Dennis
Möglichkeit Nummer 1: Die Dateien, um die es geht, haben für die Gruppe kein Leserecht. Du bist als User backup nicht der Besitzer sondern nur in der gleichen Gruppe. Wenn die Datei z.B. die Rechte -rw------- hat darfst du sie noch nicht einmal lesen. Gerhard
Gerhard, du hast ja recht! Ich hatte gedacht (ich meine dies auch irgendwo gelesen zu haben) dass ein Benutzer der in der Gruppe root ist auch auf alles zugriff hat. Wie könnte ich das noch realisieren. Ich möchte nicht chmod 777 /* machen ;-)
@Gerhard root darf alles unter linux lesen( ausser bei SE Linux o.ä. ). Die Frage ist bei welcher Datei das "Permission denied (13)" kommt. Nicht das es aus dem /proc oder /dev kommt.
Peter schrub:
> root darf alles unter linux lesen( ausser bei SE Linux o.ä. ).
Das ist zwar prinzipiell richtig nur leider völlig nutzlos - der TO hat
den Backup-User in die ★Gruppe★ 'root' aufgenommen, kein Alias für den
★User★ 'root' erzeugt.
Abgesehen davon ist es eh obligat, dass man Verzeichniss wie /proc und
/dev aus dem Backup ausnimmt.
Dennis Keipp schrieb:
> Also habe ich den Benutzer backup zur root gruppe hinzugefügt
Was spricht dagegen, den Nutzer der Gruppe wheel zuzufügen und su zu
verwenden?
Iwan
Die Vorstellung, dass ROOT alle Rechte hat ist weit verbreitet, aber falsch. ROOT kann sich nur alle rechte aneignen, das ist ein Unterschied. Die passende Vorgehensweise ist, jeweilse den Benutzer zu sein, der das darf. Mit su : root@mypc > su wasauchimmer wasauchimmer@mypc > cp ....
Gleicher Tag schrieb: > Die Vorstellung, dass ROOT alle Rechte hat ist weit verbreitet, aber > falsch. kannst du das etwas genauer beschreiben? Ich habe noch nie unter linux erlebt das man als root eine datei nicht öffnen kann, egal wie die rechte sind. Ich kenne das nur von den erweiterungen die es gibt wie z.b. SE linux.
Peter schrieb: > Ich habe noch nie unter linux > erlebt das man als root eine datei nicht öffnen kann, egal wie die > rechte sind. Dieser Fall tritt z.B. dann auf, wenn root versucht, auf ein per NFS angebundenes Netzwerk-Share zuzugreifen und der NFS-Server für root keine Zugriffe erlaubt. In solch einem Fall besitzen die Dummuser sogar höhere Zugriffsrechte als root! Jedoch kann root mittels "su - irgend einuser" den effektiven Benutzer wechseln und somit mit den Rechten des Benutzers auf das Share zugreifen. Siehe auch die diversen "squash"-Optionen in der /etc/exports.
-Auf dem fremden Rechner kann Dein lokaler su ein armer Hund sein. -Sind die Dateien zu dieser Zeit zufällig im Schreib-Zugriff ?
Hallo, Über Konsole $group [wert] [dateiname] in debian müsste dies unter 1000 sein (5 oder 500)wenn in ubuntu 1000 es der admin ist. am besten schaust dir die UID des adminstrator an wenn du selbst nicht grad selbst uneingeschränkte Rechte hast 1.leichter geht es mit dem Befehl: -Konsole öffnen -$cd pfad/ordner -su vorangesetzt; $chmod [wert]-restructive [dateiname] die Manpages in Debian helfen dir weiter da die genauen Befehle bei jedem Release abweichen können und ich kein Debian-lenny zur Zeit verwende. achso: bei Permission denied habe ich bei Ordnern (Zugriffsrechte) den Besitzer zugefügt unter welchem account dieser steht oder existiert. Und zur (Haupt)Gruppe mich (mein accountname) von dem ich aus agiere gesetzt. wie das schneller geht siehe oben Punkt 1
Nun eine Sicherung auf UNIX-Systemen erfolgt immer mit root-rechten, das bedeutet der Prozess der Objekte öffnet und liest muss mit der effektiven Userid 0 (Null) laufen, da führt kein Weg daran vorbei, ausser man möchte alles mit chmod/chown beharken was in keinster Weise zu empfehlen ist, da dann andere collateralschäden auftreten. Nun nachdem ja eine remote-Lösung mit ssh/rsync zum Einsatz kommen soll wäre mit Standard-SSH-Mitteln folgender Weg möglich. Erzeugen einer speziellen SSH-identity auf dem rufenden Rechner ohne Passwort. z.B. ssh-keygen -b 1024 -t dsa -f identity_dsa -N '' -C 'backupkey1' Eintrag des pub keys auf dem Zielrechner in root.ssh/authorized_keys mit der Option "COMMAND=/usr/bin/rsync --server --sender -logDtpre.iLs . /.". Das heisst wenn jemand dieses Key benutzt wird nur das fest zugeordnete Kommando ausgeführt und keine Shell. Auf der rufenden Seite wird nun rsync wie folgt aufgerufen: rsync -i identity_dsa -a host:/. . das würde in diesem Fall ein recursives Backup von allem machen was dranhängt. Ggf. muss man mehrere Keys und Einträge erzeugen um Dateisysteme einzeln zu sichern, dann mit der Option "-x". Achtung der benötigte Eintrag auf der Zielseite ist entsprechend anzupassen und hängt auch von den sonstigen Optionen ab die verwendet werden und ändern sich ggf. auch mit der verwendeten rsync-Version. Eine bessere Möglichkeit für limitierten automatischen Zugriff gibt es mit der Standard-SSH-Version diesbzgl. nicht.
Hey noch Was schrieb: > Die Vorstellung, dass ROOT alle Rechte hat ist weit verbreitet, aber > falsch. ROOT kann sich nur alle rechte aneignen, das ist ein > Unterschied. Quatsch. Für den klassischen Unix-root (UID 0 ist hier relevant, nicht der Benutzername!) existieren keine Zugriffsbeschränkungen. Klassischerweise findet sich unter Unix im Kernel an allen Stellen, wo Zugriffsrechte überprüft werden, Code, der ungefähr so aussieht:
1 | if (euid == 0) |
2 | return 1; |
Wobei 1 (also true) hier "Zugriff erlaubt" bedeutet. Bei neueren Unixen mit Capabilities etc. sieht das ein bisschen komplexer aus, läuft aber dennoch auf den meisten Systemen effektiv auf obiges hinaus. Mit anderen Worten: als root (UID 0) werden sämtliche Zugriffschecks einfach übersprungen, jeder beliebige Zugriff wird erlaubt. Entzieh mal einer Datei, die einem normalen Benutzer gehört sämtliche Zugriffsrechte ("chmod 0 datei"), und versuch dann mal sowohl als Eigentümer als auch als root darauf zuzugreifen. Als root gehts, als User nicht. Einzig die Executable- und die SETGID/SETUID-Bits haben auch für root Auswirkungen, allerdings weniger im Sinne von "Zugriffsrechten". Speziell aufs Executable-Bit bezogen: root kann eine Datei ausführen, sobald irgendeines der drei Executable-Bits gesetzt ist, ganz egal wie Owner oder Group bei der Datei gesetzt sind. Andreas
Andreas Ferber schrieb: > Für den klassischen Unix-root (UID 0 ist hier relevant, nicht > der Benutzername!) existieren keine Zugriffsbeschränkungen. Um auch noch auf das Problem vom Anfang des Threads einzugehen: diese kernelseitige Sonderbehandlung gilt ausschliesslich für einen Benutzer mit der UID 0 (meistens "root" genannt), aber nicht für die Gruppe mit der GID 0 (meist ebenfalls "root" genannt, ist aber nicht immer so!). Die GID 0 ist eine GID wie jede andere auch, ohne irgendwelche Extrawürste. Andreas
Иван S. schrieb: > Was spricht dagegen, den Nutzer der Gruppe wheel zuzufügen und su zu > verwenden? Dass Linux keine Gruppe namens "wheel" hat? Das ist eigentlich eine BSD-Eigenheit, dass standardmäßig nur Mitglieder der Gruppe 0 auch ein su machen dürfen. Die Gruppe "root" ist zumindest bei den meisten Linuxen offenbar der Name für die Gruppe 0. bob schrieb: > Nun eine Sicherung auf UNIX-Systemen erfolgt immer mit root-rechten, Jein. Auf BSDs erfolgt sie beim klassischen "dump"-Kommando (das man natürlich nur für lokale Dateisysteme benutzen kann) über einen direkten Zugriff auf die Gerätedatei, die daher in der Regel für die Gruppe "operator" lesbar ist. Alle für einen dump berechtigten Nutzer sind dann Mitglied dieser Gruppe. Allerdings kann natürlich bei einem gemounteten Dateisystem dann ein inkonsistenter Zustand gelesen werden, wenn sich Dateien während des dump ändern. (Aktuelle BSDs umgehen das, indem sie zuvor einen Dateisystem snapshot anlegen und dann diesen dumpen.) Für Zugriffe auf Dateisystemebene ist deine Aussage aber richtig (und darum dürfte es bei einem Linux immer gehen).
Ich gehe zur Zeit davon aus, dass ein dateibasiertes Backup erfolgen soll, und das erfolgt bei jedem Produkt das ich kenne über den normalen Dateizugriff unter user-id 0. Das beschriebene Scenario mittels ssh/rsync kenne ich bestens, zu diesem Zweck hab ich speziell Tools rund um ssh geschrieben die eine granularere Berechtigungsverteilung mit nur einem Key erlauben ohne gleich das "Scheunentor" öffnen zu müssen, aber auch nicht fix auf nur einem Kommando/ssh-Key zu beharren. Leider darf ich diese Tools nicht veröffentlichen (mein Arbeitgeber tut sich mit sowas schwer). Im Falle einer plain-ssh muss halt für jedes Remote-Kommando ein separater Key mit entsprechendem authorized_keys-Eintrag erzeugt werden. Aber auch da gibt es Fallstricke die es einem "Angreifer" bei bestimmten Konstrukten erlauben Schaden anzurichten.
Wenn man von rsync abgeht (ich habe von dem Teil zu viele Coredumps gesehen, als dass ich ihm Backup-Daten anvertrauen würde ;-), muss der Nutzer auf dem entfernten Rechner jedoch nicht "root" sein, nur der lokale Nutzer. Der auf dem entfernten Rechner (also der, der dem lokalen "root" einen Zugang ohne Passwort, nur mit ssh-Schlüssel erlauben muss, damit das alles unbeaufsichtigt ablaufen kann) kann ja "backup" heißen und besitzt keine weiteren Rechte als das Ablegen der Backups in seinem $HOME. Dort legt man dann die (ggf. komprimierten) Backup-Archive ab. Die Alternative wäre das Aufsetzen eines "richtigen" Backup-Systems. Dort läuft dann nur der file access daemon mit root-Rechten.
Jörg Wunsch schrieb: > Wenn man von rsync abgeht (ich habe von dem Teil zu viele Coredumps > gesehen, als dass ich ihm Backup-Daten anvertrauen würde ;-), muss > der Nutzer auf dem entfernten Rechner jedoch nicht "root" sein, nur > der lokale Nutzer. Der auf dem entfernten Rechner (also der, der > dem lokalen "root" einen Zugang ohne Passwort, nur mit ssh-Schlüssel > erlauben muss, damit das alles unbeaufsichtigt ablaufen kann) kann > ja "backup" heißen und besitzt keine weiteren Rechte als das Ablegen > der Backups in seinem $HOME. Dort legt man dann die (ggf. > komprimierten) Backup-Archive ab. > > Die Alternative wäre das Aufsetzen eines "richtigen" Backup-Systems. > Dort läuft dann nur der file access daemon mit root-Rechten. Selten von Dir einen so verqueren Quark gelesen. Damit ein Backup erfolgreich sein kann, muss der User/Nutzer der das Backup erstellt, natürlich alle Dateien auch lesen können. Solange da kein SUID aka Set User Id im Spiel ist, ist das der der User mit der ID 0 aka root.
blub schrieb: > Selten von Dir einen so verqueren Quark gelesen. Danke. Selten so ein komplettes Missverständnis erlebt. Ich stimme mit deinen Aussagen zu 100 % überein. Nun zeige mir bitte die Stelle, an der ich was anderes geschrieben hätte...
Jörg Wunsch schrieb: > Wenn man von rsync abgeht (ich habe von dem Teil zu viele Coredumps > gesehen, als dass ich ihm Backup-Daten anvertrauen würde ;-), muss > der Nutzer auf dem entfernten Rechner jedoch nicht "root" sein, nur > der lokale Nutzer. Der auf dem entfernten Rechner (also der, der > dem lokalen "root" einen Zugang ohne Passwort, nur mit ssh-Schlüssel > erlauben muss, damit das alles unbeaufsichtigt ablaufen kann) Stichwort rsync/ssh/...: unbedingt das Backup gründlich testen, und zwar unter realistischen Bedingungen (also nicht z.B. zum Test nur ein kleines Verzeichnis sichern), bevor man sich darauf verlässt. Ein Bekannter von mir hat mal Daten durch scp verloren. Er wollte einen Rechner neu installieren, dafür hat er ein tar seines Homedirectories gemacht und dieses via scp auf einen anderen Rechner kopiert. Dabei ist ihm leider nicht aufgefallen, dass scp die Datei bei exakt 2 GiB abgeschnitten hat, ohne Fehlermeldung. Egal welches Tool letztlich zum Einsatz kommt, man sollte sich nie unbesehen darauf verlassen, dass alles in Ordnung ist, bloss weil man keine Fehlermeldung erhalten hat. Ich selbst mache meine Backups mit Hilfe von backup2l (http://backup2l.sourceforge.net/) und afio (erweiterter cpio-Klon, http://freshmeat.net/projects/afio), Laptop etc. sichern auf einen zentralen samba-Share, und der Server selbst sichert auf eine USB-Platte. Das backup2l muss dann natürlich auf dem zu sichernden Rechner als root laufen. um alles sichern zu können. Andreas
Nun, es kommt auch darauf an, ob ein push- oder pull-Backup erfolgen soll. Bei einem push-backup, der zu sicherende Rechner legt es remote ab, stimme ich Jörg bedingt zu, kann das Ablegen der Dateien auch als nicht-root erfolgen, allerdings muss man sich Permissions und Ownership anderweitig merken, da diese dann auch verlorengeht. Bei einem pull-backup bleibt alles wie oben schon mehrfach erwähnt beim Alten.
Ich benutze für Bakcups rsnapshot+SHH Key Auth dann reicht es auch aus nur ein Komando freizugeben. ;) Der Vorteil ist halt das (so man will) halt auch mal ein paar Backups zurückgehen kann. Habe bisher (zum Glück) aber noch nie nutzen müssen.
bob schrieb: > Nun, es kommt auch darauf an, ob ein push- oder pull-Backup erfolgen > soll. Dass es um "push" ging, hätte man meiner Antwort implizit entnehmen können (da ich die Rollen ja beschrieben habe). > ..., allerdings muss man sich Permissions und Ownership > anderweitig merken, da diese dann auch verlorengeht. Dafür haben die IT-Leute Archivformate erfunden, die sowas aufzeichnen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.