Forum: PC Hard- und Software Linux Rechte, ich bitte um aufklärung


von Dennis K. (dkeipp)


Lesenswert?

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

von Gerhard (Gast)


Lesenswert?

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

von Dennis K. (dkeipp)


Lesenswert?

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 ;-)

von Peter (Gast)


Lesenswert?

@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.

von g457 (Gast)


Lesenswert?

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.

von Иван S. (ivan)


Lesenswert?

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

von Purzel H. (hacky)


Lesenswert?

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 ....

von Peter (Gast)


Lesenswert?

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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von oszi40 (Gast)


Lesenswert?

-Auf dem fremden Rechner kann Dein lokaler su ein armer Hund sein.
-Sind die Dateien zu dieser Zeit zufällig im Schreib-Zugriff ?

von g.e.e.k. inside (Gast)


Lesenswert?

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

von bob (Gast)


Lesenswert?

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.

von Andreas F. (aferber)


Lesenswert?

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

von Andreas F. (aferber)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Иван 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).

von bob (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von blub (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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...

von Andreas F. (aferber)


Lesenswert?

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

von bob (Gast)


Lesenswert?

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.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.