Jeff.Robbins.ws

I ran into this problem when was setting up a web server for usage by a team setting up our company web site. There were two developers and they both would be uploading files to the machine, and they both were going to want to modify each others files if need-be. I made a common group and set the sgid bit on the parent directory. I didn’t want to open up straight FTP access to the box so I told them to use SFTP or SCP. This worked great until I found that each users umask was not being applied to new files and directories. The two developers could see each others files but not modify them. I found that the sftp process is spawned by the root user and its umask is applied to the transaction. I wasn’t in favor or modifying the root umask so I came up with another solution.

The only thing I could find to work was to create a wrapper script around the sftp process that would temporarily set the umask for the transaction.

First I created the wrapper script:

#!/bin/bash
 
umask 0002
 
# The path to your sftp-server binary may differ
exec /usr/libexec/openssh/sftp-server

Then I pointed the Subsystem directive in the sshd_config file to my script:

Subsystem       sftp    /opt/sftp-server-wrapper.sh

A quick restart/reload of the sshd configuration and I was in business. Both users could see and edit each others files. Email or comment with questions.

—Edit (20090619)
Or even simpler still as @Gilles pointed out in the comments you can do away with the wrapper script entirely and simply change the Subsystem line in your sshd_config to this:

Subsystem sftp /bin/sh -c ‘umask 0002; /usr/libexec/openssh/sftp-server’

Thanks Gilles!

—Edit (20110525)
Or simplest yet, as @Larry and @simingol pointed out in the comments, there is a new flag for the sftp-server, ‘-u’, that allows you to directly set the umask, overriding the user umask. So to use it, just do this:

Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002