Hallo,
in einem Home-Verzeichnis liegt eine ./profile die "umask 0007" enthält. So wird eine neue Date mit den Rechten rw-rw---- erzeugt. (Der Wunsch dabei ist, immer Schreib- und Leserechte der Gruppe zu haben.) Als lokaler User und wenn ich mich per ssh einlogge, klappt das auch wunderbar.
Wenn das ganze per sshfs (mount nach x, dann touch x/datei ), oder auch scp datei user@remote erfolgt klappt es nicht, es werden nur Rechte rw-r----- vergeben.
Hat jemand eine Idee, wie das zu prüfen bzw. abzustellen wäre? (System: Lenny, sftp kann z.B. kein -u)
TIA!
Bernhard
Hallo Bernhard,
ich habe auch schon Stunden mit diesem Problem verbracht um dann irgendwo zu lesen: Das geht nicht. Weil bei der Anmeldung per SSH die .profile nicht ausgelesen wird. Lösung wäre SSH patchen.
Gerne lasse ich mich auch eines besseren belehren und wäre sogar froh wenn es eine Lösung gäbe.
Mit freundlichem Gruß,
Falk
Zitat von Bernhard Schiffner bernhard@schiffner-limbach.de:
Hallo,
in einem Home-Verzeichnis liegt eine ./profile die "umask 0007" enthält. So wird eine neue Date mit den Rechten rw-rw---- erzeugt. (Der Wunsch dabei ist, immer Schreib- und Leserechte der Gruppe zu haben.) Als lokaler User und wenn ich mich per ssh einlogge, klappt das auch wunderbar.
Wenn das ganze per sshfs (mount nach x, dann touch x/datei ), oder auch scp datei user@remote erfolgt klappt es nicht, es werden nur Rechte rw-r----- vergeben.
Hat jemand eine Idee, wie das zu prüfen bzw. abzustellen wäre? (System: Lenny, sftp kann z.B. kein -u)
TIA!
Bernhard
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hej!
sshd_config:
Subsystem sftp /bin/sh -c ‘umask 0007; /usr/libexec/openssh/sftp-server’
Beste Grüße Fabian
@Falk,
ich glaube, daß Du da falsch liegst.
ssh berücksichtigt in meinem Fall (Lenny) die umask in .profile. Wie das passiert, ist mir im Detail egal. Hauptsache, daß.
Mein Problem ist nun, daß bei Dingen, die eine nahe Verwandschaft zu ssh haben (sollten?) es _nicht_so_ passiert. Dort scheint die umask vom Typ "0027" zu sein, ich finde aber nicht raus, woher dieser Wert kommt.
Bernhard
Hallo Bernhard,
ich habe auch schon Stunden mit diesem Problem verbracht um dann irgendwo zu lesen: Das geht nicht. Weil bei der Anmeldung per SSH die .profile nicht ausgelesen wird. Lösung wäre SSH patchen.
Gerne lasse ich mich auch eines besseren belehren und wäre sogar froh wenn es eine Lösung gäbe.
Mit freundlichem Gruß,
Falk
Zitat von Bernhard Schiffner bernhard@schiffner-limbach.de:
Hallo,
in einem Home-Verzeichnis liegt eine ./profile die "umask 0007" enthält. So wird eine neue Date mit den Rechten rw-rw---- erzeugt. (Der Wunsch dabei ist, immer Schreib- und Leserechte der Gruppe zu haben.) Als lokaler User und wenn ich mich per ssh einlogge, klappt das auch wunderbar.
Wenn das ganze per sshfs (mount nach x, dann touch x/datei ), oder auch scp datei user@remote erfolgt klappt es nicht, es werden nur Rechte rw-r----- vergeben.
Hat jemand eine Idee, wie das zu prüfen bzw. abzustellen wäre? (System: Lenny, sftp kann z.B. kein -u)
TIA!
Bernhard
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Bernhard Schiffner bernhard@schiffner-limbach.de (Do 27 Jan 2011 14:22:35 CET):
Hallo,
in einem Home-Verzeichnis liegt eine ./profile die "umask 0007" enthält. So wird eine neue Date mit den Rechten rw-rw---- erzeugt. (Der Wunsch dabei ist, immer Schreib- und Leserechte der Gruppe zu haben.) Als lokaler User und wenn ich mich per ssh einlogge, klappt das auch wunderbar.
Wenn das ganze per sshfs (mount nach x, dann touch x/datei ), oder auch scp datei user@remote erfolgt klappt es nicht, es werden nur Rechte rw-r----- vergeben.
Bei SSH wird eine interaktive Shell gestarted, also .bash_profile|.bash_login|.profile eingelesen.
SCP und SSHFS nutzen halt keine interaktive Shell.
Vielleicht könntest Du experimentieren mit BASH_ENV aus bash(1), mit PermitUserEnvironment und .ssh/environment aus sshd(8) und vielleicht auch noch mit .ssh/rc aus sshd(8).
Oder Du trägst in /etc/default/ssh einfach eine Zeile
umask …
ein. Denn von dort erbt der Server die Umask. Das ist dann natürlich nicht nutzerspezifisch.
On Thursday 27 January 2011 15:30:12 Fabian Hänsel wrote:
Hej!
sshd_config:
Subsystem sftp /bin/sh -c ‘umask 0007; /usr/libexec/openssh/sftp-server’
Beste Grüße Fabian
Habe ich gemacht. Klappt.
sftp hat allerdings den lumask-Befehl. So ist eine userspezifische Einstellung besser möglich. Aber eben umask. Es werden die Gruppenrechte von "SOURCE" genommen, ge-umasked und als die primäre Gruppe "DESTINATION" ubertragen. (umask 0007) rw------- bleibt rw------- rw-rw-rw wird zu rw-rw----
Bernhard
(scp ist da nicht betroffen.)
On Thursday 27 January 2011 15:50:03 Heiko Schlittermann wrote:
Bernhard Schiffner bernhard@schiffner-limbach.de (Do 27 Jan 2011 14:22:35
CET):
Hallo,
in einem Home-Verzeichnis liegt eine ./profile die "umask 0007" enthält. So wird eine neue Date mit den Rechten rw-rw---- erzeugt. (Der Wunsch dabei ist, immer Schreib- und Leserechte der Gruppe zu haben.) Als lokaler User und wenn ich mich per ssh einlogge, klappt das auch wunderbar.
Wenn das ganze per sshfs (mount nach x, dann touch x/datei ), oder auch scp datei user@remote erfolgt klappt es nicht, es werden nur Rechte rw-r----- vergeben.
Bei SSH wird eine interaktive Shell gestarted, also .bash_profile|.bash_login|.profile eingelesen.
SCP und SSHFS nutzen halt keine interaktive Shell.
Vielleicht könntest Du experimentieren mit BASH_ENV aus bash(1), mit PermitUserEnvironment und .ssh/environment aus sshd(8) und vielleicht auch noch mit .ssh/rc aus sshd(8).
Oder Du trägst in /etc/default/ssh einfach eine Zeile
umask …ein. Denn von dort erbt der Server die Umask. Das ist dann natürlich nicht nutzerspezifisch.
Es langt ein umask 0007 in ~/.bashrc. (Etwas grob, aber nützlich.)
Dabei: Es ist mir nicht ganz klar, wann eine Änderung im .bashrc bei scp/sshfs wirksam wird. Es klappt aber im "statischen" Fall.
Die anderen Varianten verlangen mehr Testzeit ...
Danke Dir und allen anderen!
Benrhard
Hallo,
Bernhard Schiffner bernhard@schiffner-limbach.de (Do 27 Jan 2011 16:56:27 CET):
auch noch mit .ssh/rc aus sshd(8).
Oder Du trägst in /etc/default/ssh einfach eine Zeile
umask …ein. Denn von dort erbt der Server die Umask. Das ist dann natürlich nicht nutzerspezifisch.
Es langt ein umask 0007 in ~/.bashrc. (Etwas grob, aber nützlich.)
Das ist mir jetzt nicht wirklich logisch, warum sollte die nichtinteraktive Shell sich um Deine .bashrc auf der Serverseite (und davon sprechen wir hier, oder?) kümmern?
Das würde ich also genauer untersuchen.
Hast Du alles mit localhost probiert?
Dabei: Es ist mir nicht ganz klar, wann eine Änderung im .bashrc bei scp/sshfs wirksam wird. Es klappt aber im "statischen" Fall.
Die anderen Varianten verlangen mehr Testzeit ...
Auch die verwendete Variante würde ich genauer beleuchten…
Mahlzeit
Zitat von Bernhard Schiffner bernhard@schiffner-limbach.de:
On Thursday 27 January 2011 15:30:12 Fabian Hänsel wrote:
Hej!
sshd_config:
Subsystem sftp /bin/sh -c ‘umask 0007; /usr/libexec/openssh/sftp-server’
Beste Grüße Fabian
Habe ich gemacht. Klappt.
Habe ich gemacht. Klappt nicht. Wenn ich mich per sftp anmelde und Dateien erstelle hat die Gruppe nach wie vor kein Schreibrecht (rw-r--r--). Umask ist auf 0002 eingestellt.
sftp hat allerdings den lumask-Befehl. So ist eine userspezifische Einstellung besser möglich.
lumask ... muss ich mal nach googeln.
mfg fd
Hi Falk,
ich antworte hier mal auf Bernhards Vorschlaege.
On Tue, Feb 01, 2011 at 14:24:15 +0100, falk.doering@fadoe.de wrote:
sshd_config:
Subsystem sftp /bin/sh -c "umask 0007; /usr/libexec/openssh/sftp-server"
Das allein nuetzt nichts, weil das sftp-Protokoll vorsieht, dass der Client beim "put" alle Permissions der lokalen Datei auf der Remote-Seite erhalten kann ("put -P"). Eine umask verhindert kein explizites chmod.
Laut diesem Bugzilla-Eintrag gibt es aber eine Option "-u" fuer sftp-server, die wohl das nachtraegliche chmod unterdrueckt und stattdessen eine umask forciert: https://bugzilla.mindrot.org/show_bug.cgi?id=1229
Gruss, Chris
On Tuesday 01 February 2011 14:24:15 falk.doering@fadoe.de wrote:
Mahlzeit
Zitat von Bernhard Schiffner bernhard@schiffner-limbach.de:
On Thursday 27 January 2011 15:30:12 Fabian Hänsel wrote:
Hej!
sshd_config:
Subsystem sftp /bin/sh -c ‘umask 0007; /usr/libexec/openssh/sftp-server’
Beste Grüße
Fabian
Habe ich gemacht. Klappt.
Habe ich gemacht. Klappt nicht. Wenn ich mich per sftp anmelde und Dateien erstelle hat die Gruppe nach wie vor kein Schreibrecht (rw-r--r--). Umask ist auf 0002 eingestellt.
sftp hat allerdings den lumask-Befehl. So ist eine userspezifische Einstellung besser möglich.
lumask ... muss ich mal nach googeln.
mfg fd
Prüfe mal bitte, ob die Dateien auf der "Erzeugerseite" die "richtigen" Gruppenrechte haben. Klar: umask setzt keine Rechte, sondern setzt nur zurück.
sftp kopiert scheinbar nur dumm (im Sinne alter owner wird neuer owner, alte group wird neue group usw. ) die "Erzeugerseitenrechte" und wendet darauf das umask der "fernen" .bashrc an.
Etwa so: ich:ich umask 0007 touch dies rw-rw---- dies sftp dies du@irgendwo (du:du umask 0007) rw-rw---- dies
Bernhard
On Thursday 27 January 2011 23:30:34 Heiko Schlittermann wrote:
Hallo,
Bernhard Schiffner bernhard@schiffner-limbach.de (Do 27 Jan 2011 16:56:27
CET):
auch noch mit .ssh/rc aus sshd(8).
Oder Du trägst in /etc/default/ssh einfach eine Zeile
umask …ein. Denn von dort erbt der Server die Umask. Das ist dann natürlich nicht nutzerspezifisch.
Es langt ein umask 0007 in ~/.bashrc. (Etwas grob, aber nützlich.)
Das ist mir jetzt nicht wirklich logisch, warum sollte die nichtinteraktive Shell sich um Deine .bashrc auf der Serverseite (und davon sprechen wir hier, oder?) kümmern?
Das würde ich also genauer untersuchen.
Hast Du alles mit localhost probiert?
Wie wichtig ist Dir das? (Ich habe die Maschinen z.Z. nicht im Zugriff und sftp ist dort auch nicht Verbindungsmethode der Wahl, eher sshfs (a la sftp!) und ssh.)
Ich habe es nicht mit localhost, sondern richtigen Rechnern (2*Lenny, 1*Suse) probiert. Wie gesagt, es ging nicht immer auf Anhieb richtig, wenn's aber mal lief , lief's richtig und stabil. IMHO macht es für sftp schon Sinn, sich im Zielverzeichnis mal über die Regeln (owner, group, umask) klarzuwerden, und entsprechend "dumm" (1:1 Kopie der Rechte ~& umask ) zu handeln.
Bernhard
Bernhard Schiffner bernhard@schiffner-limbach.de (Mi 02 Feb 2011 09:21:02 CET):
On Thursday 27 January 2011 23:30:34 Heiko Schlittermann wrote:
Hallo,
Bernhard Schiffner bernhard@schiffner-limbach.de (Do 27 Jan 2011 16:56:27
CET):
auch noch mit .ssh/rc aus sshd(8).
Oder Du trägst in /etc/default/ssh einfach eine Zeile
umask …ein. Denn von dort erbt der Server die Umask. Das ist dann natürlich nicht nutzerspezifisch.
Es langt ein umask 0007 in ~/.bashrc. (Etwas grob, aber nützlich.)
Das ist mir jetzt nicht wirklich logisch, warum sollte die nichtinteraktive Shell sich um Deine .bashrc auf der Serverseite (und davon sprechen wir hier, oder?) kümmern?
Das würde ich also genauer untersuchen.
Hast Du alles mit localhost probiert?
Wie wichtig ist Dir das?
Na, die Idee war, daß Du dann Opfer Deiner selbst geworden sein könntest bei so Dingen wie
ssh localhost
On Thursday 03 February 2011 01:16:46 Heiko Schlittermann wrote: ...
Hast Du alles mit localhost probiert?
Wie wichtig ist Dir das?
Na, die Idee war, daß Du dann Opfer Deiner selbst geworden sein könntest bei so Dingen wie
ssh localhost
:-) Opfer meinerselbst werde ich oft genug. Eine Bekannte hat es vor langer Zeit aber hoffnungsvoll so gesagt: "Schlimm ist nicht das Brett (vor dem Kopf), sondern die Schraube!".
Danke für alle Hilfe soweit! (Das man umask in so ziemlich alles reinbringen kann, was "gesourced" (.) werden kann, war mir ein neuer Gedanke.)
Bernhard
lug-dd@mailman.schlittermann.de
-
"Fabian Hänsel" -
Bernhard Schiffner -
Christian Perle -
falk.doering＠fadoe.de -
Heiko Schlittermann