Le serveur OpenSSH SFTP utilise-t-il umask ou conserve-t-il les autorisations côté client après la commande put (environnement chrooté)?


13

Je sais que cette question a déjà été discutée, mais en lisant les articles, je n'ai pas pu trouver les réponses, car certains ont dit "oui, umask peut fonctionner", et d'autres ont dit "La commande de mise OpenSSH conserve toujours les autorisations"

Avant tout juste pour préciser:

  • J'utilise OpenSSH 5.9 sur RHEL 6.2
  • J'ai configuré un serveur SFTP chrooté, en utilisant le internal-sftpsous-système, avec -u 0002pour umask
  • Je précise que je n'utilise pas l' option -pou-P

D'après ce que j'ai lu d'une part: il existe de nombreuses façons de définir umask pour les transferts SFTP:

  • possibilité -ude internal-sftp(ou sftp-server), depuis OpenSSH 5.4
  • créer un wrapper pour sftp-server(dans lequel nous définissons explicitement le umask - cela ne convient pas à l'environnement chrooté btw)
  • ajouter une configuration spécifique dans le pam.d/sshdfichier

Par contre j'ai lu:

Le client et le serveur OpenSSH SFTP transfèrent les autorisations (en tant qu'extension) et créent le fichier distant avec les autorisations du côté local. AFAICT, il n'y a aucun moyen de désactiver ce comportement.

J'ai donc fait le test suivant:

Sur mon client, j'ai créé un fichier MYFILEet un répertoire MYDIRavec les autorisations 600 et 700.

Puis avec des sftpcommandes:

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)

Si je modifie les autorisations de MYFILEet MYDIRcôté client et que je les télécharge à nouveau, j'obtiens les nouvelles autorisations côté serveur.

J'ai également essayé la pam.dsolution, mais cela n'a rien changé.

Alors maintenant, je suis confus:

D'après ce que j'ai testé et une partie de ce que j'ai lu, je dirais qu'OpenSSH conserve toujours les autorisations. Mais comme de nombreux articles disent qu'un umask pourrait être défini, je peux imaginer que je fais une mauvaise chose dans mes configurations de test.

J'apprécierais quelques commentaires expérimentés.

Je vous remercie.

Réponses:


12

Tout d'abord, l'umask concerne le serveur et non le client. Donc, demander si la putcommande du client OpenSSH utilise umask est faux. Vous devriez demander si le serveur OpenSSH utilise umask lors de la création d'un fichier à la suite du téléchargement SFTP.

Quoi qu'il en soit, ce que fait le client OpenSSH SFTP:

  • putsans -Pindicateur, il demande au serveur de créer un fichier avec les mêmes autorisations que le fichier local. Le serveur OpenSSH applique alors (implicitement par les règles * nix) le umask.

  • putavec l' -Pindicateur, il démarre de la même manière, mais une fois le téléchargement terminé, le client demande au serveur de (re) définir explicitement les autorisations de la même manière que le fichier local (demande "chmod"). Pour "chmod", le umask ne s'applique pas.

  • mkdir, il demande au serveur de créer un répertoire avec les autorisations 0777. Le umask s'applique implicitement.

Quoi qu'il en soit, je crois que umask 0002 n'a aucun effet sur le fichier avec les autorisations 0600, car elles s'excluent mutuellement. Vous devriez essayer votre umask contre un fichier avec des autorisations comme 0644.

Donc, en fait, cela devrait fonctionner, si vous avez configuré votre système comme vous le décrivez. Voir les preuves de ma boîte (Ubuntu avec OpenSSH 6.2p2)

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

Voyez la différence dans les autorisations après 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, la dernière spécification SFTP définit le comportement du client et du serveur concernant umask. Comme vous pouvez le voir, OpenSSH viole réellement cela, bien que l'OpenSSH implémente SFTP version 3 qui n'avait pas encore mentionné umask.

7.6. Autorisations

...

Le serveur NE DEVRAIT PAS appliquer un «umask» aux bits de mode; mais doit définir les bits de mode comme spécifié par le client. Le client DOIT appliquer un «umask» approprié aux bits de mode avant de les envoyer.


J'ai déjà essayé avec de nombreuses autorisations différentes, au tout début, j'avais 755 pour mon répertoire côté client et je voulais obtenir 775 à la place. Mais ça n'a pas marché. Je suis d'accord avec vous pour le -P en lisant la documentation, mais même sans cet indicateur, j'obtiens toujours sur le serveur les mêmes autorisations que le client (quelles que soient les autorisations)
drkzs

merci pour la remarque, j'ai essayé d'améliorer le titre et de corriger un terme
drkzs

Cela devrait fonctionner, voir ma mise à jour.
Martin Prikryl

Oui, votre exemple fonctionne ... mais si vous remplacez umask par 0002, il ne fonctionne plus. Peut-être que ce message pose le même problème? sauf que je suis dans openssh5.9 et que l'option umask devrait fonctionner. La différence entre votre configuration SSHD et la mienne est que je n'utilise pas ForceCommand, donc je spécifie l'umask dans la ligne de sous-système. (J'essaierai de poster la configuration et le résultat, mais le test du réseau n'est pas facilement accessible)
drkzs

1
Juste pour être clair sur ce point: The server SHOULD NOT apply a 'umask' ne s'applique que lorsque le client envoie des informations de permission . Lorsque le client n'envoie pas d'informations de permission, il est prévu que le comportement applique un umask!
heiglandreas
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.