Verwendet der OpenSSH-SFTP-Server umask oder behält er die clientseitigen Berechtigungen nach dem Befehl put bei (chrooted environment)?


13

Ich weiß, dass diese Frage bereits besprochen wurde, aber beim Lesen der Beiträge konnte ich die Antworten nicht finden, da einige sagten: "Ja, umask kann funktionieren", und andere sagen: "OpenSSH put-Befehl bewahrt immer Berechtigungen".

Vor allem nur um genau zu sein:

  • Ich benutze OpenSSH 5.9 auf RHEL 6.2
  • Ich habe einen Chroot-SFTP-Server mit internal-sftpSubsystem -u 0002für umask konfiguriert
  • Ich benutze die Option -poder nicht-P

Zum einen habe ich gelesen: Es gibt viele Möglichkeiten, umask für SFTP-Übertragungen zu definieren:

  • Option -uvon internal-sftp(oder sftp-server), seit OpenSSH 5.4
  • erstelle einen Wrapper für sftp-server(in dem wir die umask explizit setzen - das passt übrigens nicht für chroot-Umgebungen)
  • Fügen Sie eine bestimmte Konfiguration in die pam.d/sshdDatei ein

Andererseits habe ich gelesen:

Der OpenSSH SFTP-Client und -Server übertragen die Berechtigungen (als Erweiterung) und erstellen die Remote-Datei mit den Berechtigungen auf der lokalen Seite. AFAICT, es gibt keine Möglichkeit, dieses Verhalten zu deaktivieren.

Also habe ich folgenden Test gemacht:

Auf meinem Client habe ich eine Datei MYFILEund ein Verzeichnis MYDIRmit den Berechtigungen 600 und 700 erstellt.

Dann mit sftpBefehlen:

mkdir => the new directory has permissions following the umask (OK)
put MYFILE => MYFILE has same permissions as on client (KO)
put -r MYDIR => MYDIR has same permissions as on client (KO)

Wenn ich die Berechtigungen von MYFILEund MYDIRauf der Clientseite ändere und erneut hochlade, erhalte ich die neuen Berechtigungen auf der Serverseite.

Ich habe die pam.dLösung auch ausprobiert , aber es hat sich nichts geändert.

Jetzt bin ich verwirrt:

Nach dem, was ich getestet habe und einem Teil dessen, was ich gelesen habe, würde ich sagen, dass OpenSSH immer Berechtigungen beibehält. Aber da es viele Posts gibt, die besagen, dass eine Umask definiert werden könnte, kann ich mir vorstellen, dass ich in meinen Testkonfigurationen etwas Falsches mache.

Ich würde mich über erfahrene Rückmeldungen freuen.

Vielen Dank.

Antworten:


12

Erstens geht es bei der umask um den Server und nicht um den Client. putEs ist also falsch zu fragen, ob der Befehl des OpenSSH-Clients umask verwendet. Sie sollten fragen, ob der OpenSSH-Server beim Erstellen einer Datei als Ergebnis des SFTP-Uploads umask verwendet.

Wie auch immer, was OpenSSH SFTP-Client macht:

  • putOhne -PFlag wird der Server aufgefordert, eine Datei mit den gleichen Berechtigungen wie die lokale Datei zu erstellen. Der OpenSSH-Server wendet dann (implizit nach * nix-Regeln) die umask an.

  • putmit dem -PFlag wird es gleich gestartet, aber nachdem der Upload abgeschlossen ist, fordert der Client den Server auf, die Berechtigungen explizit auf dieselben wie die lokale Datei ("chmod" -Anforderung) zu setzen (neu zu setzen). Für "chmod" gilt die umask nicht.

  • mkdirfordert den Server auf, ein Verzeichnis mit den Berechtigungen 0777 zu erstellen. Die umask gilt implizit.

Jedenfalls glaube ich, dass umask 0002 keine Auswirkung auf die Datei mit den Berechtigungen 0600 hat, da sich diese gegenseitig ausschließen. Sie sollten Ihre umask gegen eine Datei mit Berechtigungen wie 0644 versuchen.

Eigentlich sollte es funktionieren, wenn Sie Ihr System so konfiguriert haben, wie Sie es beschreiben. Siehe Beweise aus meiner Box (Ubuntu mit OpenSSH 6.2p2)

Match user user2
  ChrootDirectory /home/user2/chroot
  ForceCommand internal-sftp -u 0077
  AllowTcpForwarding no
  PermitTunnel no
  X11Forwarding no

Sehen Sie den Unterschied in den Berechtigungen nach putvs put -P.:

user1:~$ touch file.txt
user1:~$ ls -l
total 0
-rw-r--r-- 1 user1 ftpuser    0 Oct 23 15:34 file.txt
user1:~$ sftp user2@localhost
user2@localhost's password: 
Connected to localhost.
sftp> cd somefolder 
sftp> put file.txt
Uploading file.txt to /somefolder/file.txt
file.txt                                         100%     0    0.0KB/s    0:00
sftp> ls -l
-rw-------    1 1003 1001    0 Oct 23 15:35 file.txt
sftp> put -P file.txt
Uploading file.txt to /somefolder/file.txt
file.txt                                         100%     0    0.0KB/s    0:00
sftp> ls -l
-rw-r--r--    1 1003 1001    0 Oct 23 15:34 file.txt

Btw, die neueste SFTP - Spezifikation definiert das Verhalten des Clients und Server über umask. Wie Sie sehen, verstößt OpenSSH tatsächlich dagegen, obwohl OpenSSH SFTP Version 3 implementiert, in der umask noch nicht erwähnt wurde.

7.6. Berechtigungen

...

Der Server SOLLTE KEINE 'umask' auf die Modusbits anwenden. sollte aber die vom Client festgelegten Modusbits setzen. Der Client MUSS vor dem Senden eine entsprechende 'umask' auf die Modusbits anwenden.


Ich habe es bereits mit vielen verschiedenen Berechtigungen versucht, am Anfang hatte ich 755 für mein Verzeichnis auf der Clientseite und wollte stattdessen 775 erhalten. Aber es hat nicht funktioniert. Ich stimme Ihnen für die -P durch Lesen der Dokumentation zu, aber auch ohne dieses Flag bekomme ich auf dem Server immer die gleichen Berechtigungen wie auf dem Client (unabhängig von den Berechtigungen)
drkzs


Es sollte eigentlich funktionieren, siehe mein Update.
Martin Prikryl

Ja, dein Beispiel funktioniert ... aber wenn du umask auf 0002 änderst, funktioniert es nicht mehr. Vielleicht wirft dieser Beitrag das gleiche Problem auf? mit der Ausnahme, dass ich mich in openssh5.9 befinde und dass die Option umask funktionieren sollte. Der Unterschied zwischen Ihrer und meiner SSHD-Konfiguration besteht darin, dass ich ForceCommand nicht verwende. Daher gebe ich die umask in der Subsystemzeile an. (Ich werde versuchen, die Konfiguration und das Ergebnis zu veröffentlichen, aber der Netzwerktest ist nicht leicht zu erreichen)
drkzs

1
Um diesbezüglich klar zu sein: The server SHOULD NOT apply a 'umask' Gilt nur, wenn der Client Berechtigungsinformationen sendet . Wenn der Client keine Berechtigungsinformationen sendet, ist es beabsichtigt, eine umask anzuwenden!
Heiglandreas
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.