Dateien kopieren, Rechte an Umgebung anpassen
Ich benutze Suse 9.3 bzw. 10.0. Nach langen Windows-Jahren habe ich in der letzten Zeit eine Menge gelernt, stoße aber immer wieder auf Schwierigkeiten, zu denen mir trotz Suchen und Lesen irgendwann nichts mehr einfällt. Hier ist ein Beispiel: Der lokale Entwicklungs- und Testserver hat Kopien der Domains, die öffentlich sichtbar sind. Jede Domain hat einen eigenen ftp- Benutzer, der sich nur innerhalb der Domain bewegen darf. Die Domains benutzen z.T. kleine, selbst geschriebene PHP-Routinen, z.B. um Menüs und Fußzeilen einzublenden. Eines dieser Skripte wird verändert und getestet, dann soll es auf die Domains verteilt werden. Jetzt ist die Frage: Welche Domains benutzen dieses Skript überhaupt? Sicher nicht alle, so viel weiß ich. Soll ich jetzt wirklich ein Dutzendmal den ftp-Benutzer wechseln und mich mit den Domains verbinden, um herauszufinden, wo das Skript gebraucht wird und wo nicht? Zu umständlich. Als root lasse ich mir das auf dem Entwicklungsserver mit "find" anzeigen. Ergebnis: 6 von 12 Domains benutzen das Skript und brauchen das Update. Also kopiere ich das Skript sechsmal rüber. Beim nächsten Besuch der Domains als ftp-Benutzer merke ich dann, was ich vergessen habe. Die Rechte stimmen nicht, und der ftp- Benutzer darf nicht mehr dran. Was mir dazu einfällt: - sechsmal kopieren und sechsmal mit chown zuweisen. Umständlich. - sechsmal als ftp-Benutzer anmelden, sechsmal hochladen. Auch umständlich. Dazu käme dann noch, dass die Dateien weitere sechs Mal von den lokalen Domains auf die Produktivdomains übertragen werden müssen. Wie kann man so etwas regelkonform, unter Sicherheitsaspekten einwandfrei UND effizient erledigen? cp -p erhält den Besitzer, aber wie passe ich beim Kopieren möglichst automatisch den Besitzer an? Ich hab mal nach "inherit ownership" usw. gesucht, finde aber nichts Passendes. Gibt es vielleicht im Suse-Paket sogar ein nachzuinstallierendes Tool, das mir bei solchen Aufgaben hilft? Was machen eigentlich Leute, die auf einen Schlag nicht nur ein halbes Dutzend, sondern ein paar hundert Domains mit Updates versorgen müssen? So was soll's ja geben, glaube ich. Vielleicht können alte Hasen darüber nur lachen, aber ich stolpere immer wieder über solche Kleinigkeiten und weiß manchmal einfach nicht, wo ich nachsehen/lesen könnte. Oder übersehe ich vielleicht etwas völlig Banales? Danke schon mal für eure Tipps Jürgensuse-linux@suse.com
Juergen Langowski wrote:
Ich benutze Suse 9.3 bzw. 10.0. Nach langen Windows-Jahren habe ich in der letzten Zeit eine Menge gelernt, stoße aber immer wieder auf Schwierigkeiten, zu denen mir trotz Suchen und Lesen irgendwann nichts mehr einfällt.
Hier ist ein Beispiel:
Der lokale Entwicklungs- und Testserver hat Kopien der Domains, die öffentlich sichtbar sind. Jede Domain hat einen eigenen ftp- Benutzer, der sich nur innerhalb der Domain bewegen darf. Die Domains benutzen z.T. kleine, selbst geschriebene PHP-Routinen, z.B. um Menüs und Fußzeilen einzublenden.
Eines dieser Skripte wird verändert und getestet, dann soll es auf die Domains verteilt werden.
Jetzt ist die Frage: Welche Domains benutzen dieses Skript überhaupt? Sicher nicht alle, so viel weiß ich. Soll ich jetzt wirklich ein Dutzendmal den ftp-Benutzer wechseln und mich mit den Domains verbinden, um herauszufinden, wo das Skript gebraucht wird und wo nicht? Zu umständlich.
Als root lasse ich mir das auf dem Entwicklungsserver mit "find" anzeigen. Ergebnis: 6 von 12 Domains benutzen das Skript und brauchen das Update.
Also kopiere ich das Skript sechsmal rüber.
Okay, soweit in Ordnung.
Beim nächsten Besuch der Domains als ftp-Benutzer merke ich dann, was ich vergessen habe. Die Rechte stimmen nicht, und der ftp- Benutzer darf nicht mehr dran.
Grins!
Was mir dazu einfällt:
- sechsmal kopieren und sechsmal mit chown zuweisen. Umständlich. - sechsmal als ftp-Benutzer anmelden, sechsmal hochladen. Auch umständlich.
Das solltest du mit einem Script machen. Ich musste das bisher nicht machen, aber es hat ungefähr 5 Minuten gedauert, bis ich das richtige Kommando (auf Suse 9.2) gefunden hatte. Wenn du die Datei gefunden hast mit find, dann mache VOR DEM KOPIEREN!! folgendes: previous_owner=`stat -c%U $filename_to_be_overwritten` previous_group=`stat -c%U $filename_to_be_overwritten` access_mode=`stat -c%a $filename_to_be_overwritten` cp $newfile $filename_to_be_overwritten chown $previous_owner:$previous_group $filename_to_be_overwritten chmod $access_mode $filename_to_be_overwritten Ich habe es jetzt nicht getestet, aber das sollte dein Problem beseitigen, egal, wer der Besitzer der Datei ist und wieviele Domains du verwalten musst.
Dazu käme dann noch, dass die Dateien weitere sechs Mal von den lokalen Domains auf die Produktivdomains übertragen werden müssen.
Wie kann man so etwas regelkonform, unter Sicherheitsaspekten einwandfrei UND effizient erledigen?
Scripten. Siehe oben.
cp -p erhält den Besitzer, aber wie passe ich beim Kopieren möglichst automatisch den Besitzer an? Ich hab mal nach "inherit ownership" usw. gesucht, finde aber nichts Passendes. Gibt es vielleicht im Suse-Paket sogar ein nachzuinstallierendes Tool, das mir bei solchen Aufgaben hilft?
Was machen eigentlich Leute, die auf einen Schlag nicht nur ein halbes Dutzend, sondern ein paar hundert Domains mit Updates versorgen müssen? So was soll's ja geben, glaube ich.
Scripten.
Vielleicht können alte Hasen darüber nur lachen, aber ich stolpere immer wieder über solche Kleinigkeiten und weiß manchmal einfach nicht, wo ich nachsehen/lesen könnte. Oder übersehe ich vielleicht etwas völlig Banales?
Banal ist das ganze nur, wenn man das schon viele male gemacht hat. Das Problem beim Scripten ist, dass man erst einmal einen gewissen Fundus an Programmen kennen muss, bevor man genügend Kombinationsmaterial hat, um das gewünschte Ergebnis zu erreichen. Manche Sachen stellen sich als sehr einfach heraus, während andere nur noch Kopfzerbrechen bereiten, weil dauernd Sicherheitsaspekte oder Komplikationen (Sonderzeichen, Zeichensätze, Leerzeichen, unkontrollierte Usereingaben etc.) auftauchen, die vorher nicht berücksichtigt wurden. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic schrieb: (...)
Wenn du die Datei gefunden hast mit find, dann mache VOR DEM KOPIEREN!! folgendes:
previous_owner=`stat -c%U $filename_to_be_overwritten` previous_group=`stat -c%U $filename_to_be_overwritten`
Für die Gruppe müsste es wohl stat -c%G heißen, nehme ich an? Auf stat wäre ich erst mal nicht gekommen. Nach deinem Hinweis sieht es auf einmal viel einfacher aus.
access_mode=`stat -c%a $filename_to_be_overwritten`
cp $newfile $filename_to_be_overwritten chown $previous_owner:$previous_group $filename_to_be_overwritten chmod $access_mode $filename_to_be_overwritten
Ich habe es jetzt nicht getestet, aber das sollte dein Problem beseitigen, egal, wer der Besitzer der Datei ist und wieviele Domains du verwalten musst.
Und das Ganze in ein Skript packen, und schon habe ich ein neues Werkzeug. Klasse, so müsste das gehen. Danke! Jürgen
Juergen Langowski wrote:
Sandy Drobic schrieb:
(...)
Wenn du die Datei gefunden hast mit find, dann mache VOR DEM KOPIEREN!! folgendes:
previous_owner=`stat -c%U $filename_to_be_overwritten` previous_group=`stat -c%U $filename_to_be_overwritten`
Für die Gruppe müsste es wohl stat -c%G heißen, nehme ich an?
Uups, böses copy/paste. Ja, -c%G zeigt die Gruppe an.
Auf stat wäre ich erst mal nicht gekommen. Nach deinem Hinweis sieht es auf einmal viel einfacher aus.
Das meinte ich mit "Fundus an Befehlen". Es ginge auch mit der Ausgabe von ls. previous_owner=`ls -l $file_to_be_overwritten| awk '{print $3}'` previous_group=`ls -l $file_to_be_overwritten| awk '{print $4}'` Die Rechte müsste man sich eben aus dem zweiten Feld herauspicken. Etwas mühseliger, geht aber auch. rechte=`ls -l $filename_to_be_overwritten | awk '{print $1}'` owner_rights=${rechte:1:3} owner_rights=`echo $owner_rights | tr -d '-'` Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo, Am Sam, 16 Sep 2006, Juergen Langowski schrieb: [..]
Als root lasse ich mir das auf dem Entwicklungsserver mit "find" anzeigen. Ergebnis: 6 von 12 Domains benutzen das Skript und brauchen das Update.
Also kopiere ich das Skript sechsmal rüber.
Beim nächsten Besuch der Domains als ftp-Benutzer merke ich dann, was ich vergessen habe. Die Rechte stimmen nicht, und der ftp- Benutzer darf nicht mehr dran.
Was mir dazu einfällt:
- sechsmal kopieren und sechsmal mit chown zuweisen. Umständlich. - sechsmal als ftp-Benutzer anmelden, sechsmal hochladen. Auch umständlich.
Dazu käme dann noch, dass die Dateien weitere sechs Mal von den lokalen Domains auf die Produktivdomains übertragen werden müssen.
Wie kann man so etwas regelkonform, unter Sicherheitsaspekten einwandfrei UND effizient erledigen?
Schnellschuss:
Domains finden:
DOMAINS="`find ...`"
dabei sollen find plus Nachbearbeitung die Liste der Domains
ausgeben. In DOMAINS steht dann z.B. durch Leerzeichen getrennt
$ echo "'$DOMAINS'"
'foo.de bar.de example.com'
Wie du das hinbekommst haengt von der Ordnerstruktur ab. Schau dir
auf jeden Fall den -printf Befehl von find an.
Das ganze wird dann als Funktion verpackt.
Wenn du das hast:
==== WIRD SO NICHT FUNKTIONIEREN! Dies soll NUR eine Anregung sein! ====
UPUSER="uploaduser"
UPDIR="/home/uploaduser/tmp"
SERVER="servername"
DOMROOT="/srv/www"
find_domains() {
find ... -name "$1" ... -printf ...
}
for datei; do
### Domains mit $datei finden
DOMAINS="`find_domains \"$datei\"`"
### ins uploaddir raufladen
### auskommentiert um erstmal die inst-script Generierung testen
# scp "$datei" "${UPUSER}@${SERVER}:${UPDIR}"
upfile="${UPDIR}/${datei}"
### shell-script auf stdout erzeugen
{
### fuer jede Domain, die die Datei bekommen soll
for dom in $DOMAINS; do
### finde user und gruppe zur jew. Domain
domuser="..."
domgrp="..."
### shell-fragment "install" mit Rechten
cat <
Hallo Jürgen, hallo Leute, die technische Seite wurde ja schon ausführlich behandelt. Kommen wir jetzt zum Thema Sicherheit ;-) Am Samstag, 16. September 2006 15:35 schrieb Juergen Langowski:
Wie kann man so etwas regelkonform, unter Sicherheitsaspekten einwandfrei UND effizient erledigen?
Wenn der Benutzer im Verzeichnis Schreibrechte hat, wird es lustig ;-) Kleines Beispiel zur Abschreckung: # ls -l foo bar lrwxrwxrwx 1 cb users 3 2006-09-16 18:22 bar -> foo -rw-r--r-- 1 cb users 0 2006-09-16 18:22 foo # cp irgendwas bar # ls -l foo bar lrwxrwxrwx 1 cb users 3 2006-09-16 18:22 bar -> foo -rw-r--r-- 1 cb users 1923 2006-09-16 18:23 foo Sprich: Durch Setzen eines passenden Symlinks lassen sich Dateien überschreiben. Wenn das Script als Root läuft, auch die Dateien anderer User oder Systemdateien. (klassische "Symlink attack") Wenn Du jetzt spontan an "vorher löschen" denkst, vergiss es bitte gleich wieder. Die Situation hat sich zwar dahingehend verbessert, dass Du aus einem permanenten Problem eine race condition gemacht hast - aber es könnte immer noch jemand zwischen Löschen und Kopieren einen neuen Symlink anlegen. Die Lösung ist, das Kopieren als User laufen zu lassen - wenn dann ein User einen bösen Symlink auf fremde Dateien setzt, kommt schlicht "permission denied". Da Dein Script ja schon als root läuft: su username -c "cp /pfad/zur/datei /da/hin" chown, ein weiteres potenzielles Sicherheitsrisiko, ist logischerweise überflüssig, weil der User keine Dateien mit Besitzer root anlegen kann ;-) Bezüglich Usernamen und Homeverzeichnissen würde ich folgendes empfehlen ("grep /home/hostings/" nach Bedarf anpassen): getent passwd | grep /home/hostings/ | { IFS=: read user x x x x homedir x ; su "$user" -c "cp /pfad/zur/datei $homedir/da/hin" } Warum die geschweiften Klammern nötig sind, kannst Du auf www.cboltz.de/de/linux/bash/sl nachlesen ;-) Gruß Christian Boltz --
Das dich das überrascht, überrascht mich jetzt aber :-) Das überrascht mich aber durchaus. Überraschend. [>> René Falk, > Ratti und Arno Lehmann in suse-linux]
Gruß Christian Boltz -- Failure is not an option. It comes bundled with your Microsoft product.
participants (5)
-
Christian Boltz -
David Haller -
Juergen Langowski -
Martin Schröder -
Sandy Drobic