There is no way to set a default umask for the SFTP server. Steps to Reproduce: 1. Enable SFTP server. 2. Connect using command-line sftp client. 3. Put a file to the server. 4. ls -l, and you'll see that the file has not been created group-writable. Expected Results There should either be some way to configure the server so that the default umask will be as desired, such as 0002, or the file should take the umask and group id from the enclosing parent folder. This is a must if multiple developers are to use SFTP to work on the same set of files in the web server, for example. Actual Results: The server always creates files with its own umask, the default of which cannot be changed. Workaround: Use FTP instead, and risk having your passwords stolen.
(In reply to comment #0) > There is no way to set a default umask for the SFTP server. [...] > Workaround: Use FTP instead, and risk having your passwords stolen. Another workaround: sftp-server inherits it umask from the shell (since it's run via "sh -c") so you can set it in /etc/profile or equivalent. That said, since sftp-server understands arguments these days then adding one for umask might be a reasonable idea.
I think there's a bunch of Gentoo users including me that are interested in this feature aswell, now that the Gentoo core system packages team decided to ditch the sftplogging (http://sftplogging.sourceforge.net/) features of the openssh ebuild. See my ticket at http://bugs.gentoo.org/show_bug.cgi?id=154440
Created attachment 1205 [details] Add -u option to sftp-server This is easy now that sshd_config Subsystem declarations (and sftp-server) can accept commandline arguments. This patch adds a -u option to sftp-server to set an explicit umask. Please test.
I have just tested your patch against openssh 4.5p1 and it works fine for the umask-setting part. I did add a small change to process_open to mimic the behavior of the sftplogging patch, which is to set the mode to 0666 to force the umask on newly created files. Same for process_mkdir, with mode 0777.
We should look at this for the 5.4 release.
Created attachment 1673 [details] Revised patch
patch applied. This will be in openssh-5.4
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.
*** Bug 1715 has been marked as a duplicate of this bug. ***
With the release of 5.4p1, this bug is now considered closed.