Bug 859238

Sorry, the Release number should have been 81.el6.

Another correction. sftp-server implements chroot via the necessary files and directories to support the user's session. internal-sfp only requires the directory location and correct permissions.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

I tested the umask functionality with openssh-5.3p1-94.el6
using following line in sshd_config:
  Subsystem sftp internal-sftp -u 0077

# service sshd restart

$ sftp user@localhost
Connecting to localhost...
user@localhost's password: 
sftp> put /tmp/testfile
Uploading /tmp/testfile to /home/user/testfile
/tmp/testfile                                                               100%    0     0.0KB/s   00:00    
sftp> ls -l testfile
-rw-------    0 501      501             0 Mar 11 08:01 testfile
sftp> ^D

The above seem to be correct.

I am not sure how to understand chgrp, chown, and chmod in this context. I am not aware of such options in sftp-server.

This doesn't look like a bug at all and I tend to close this as WORKSFORME. It seems that there's some confusion about what umask(2) is.

rhel-6 # grep Subsys /etc/ssh/sshd_config
Subsystem sftp internal-sftp -l VERBOSE -f LOCAL6 -u 0000

client $ touch file; chmod 777 file

client $ sftp root@rhel-6
Connected to rhel-6-preup.
sftp> put file
Uploading file to /root/file
file                                         100%    0     0.0KB/s   00:00    
sftp> ls -l file
-rwxrwxrwx    0 0        0               0 Mar 12 12:38 file
sftp> rm file
Removing /root/file

--------

rhel-6 # grep Subsys /etc/ssh/sshd_config
Subsystem sftp internal-sftp -l VERBOSE -f LOCAL6 -u 0777

rhel-6 # service sshd restart

client $ touch file; chmod 777 file

client $ sftp root@rhel-6
Connected to rhel-6-preup.
sftp> put file
Uploading file to /root/file
file                                         100%    0     0.0KB/s   00:00    
sftp> ls -l file
----------    0 0        0               0 Mar 12 12:40 file
sftp> rm file
Removing /root/file

Regarding the patch, there's a problematic copyright clause, which I'm not sure we can accomplish. 

The patch adds new configuration options to sshd_config instead using command line arguments similar to current -u option. 

The upstream recently [1] added an ability to white/blacklist sftp protocol requests. But this is not even released yet and there's no  assurance that it's backportable to rhel-6 openssh package.

[1] https://anongit.mindrot.org/openssh.git/commit/?id=6eaeebf27d92f39a38c772aa3f20c2250af2dd29

(In reply to Petr Lautrbach from comment #10)
> This doesn't look like a bug at all and I tend to close this as WORKSFORME.
> It seems that there's some confusion about what umask(2) is.
> 
> rhel-6 # grep Subsys /etc/ssh/sshd_config
> Subsystem sftp internal-sftp -l VERBOSE -f LOCAL6 -u 0000
> 
> client $ touch file; chmod 777 file
> 
> client $ sftp root@rhel-6
> Connected to rhel-6-preup.
> sftp> put file
> Uploading file to /root/file
> file                                         100%    0     0.0KB/s   00:00  
> 
> sftp> ls -l file
> -rwxrwxrwx    0 0        0               0 Mar 12 12:38 file
> sftp> rm file
> Removing /root/file
> 
> --------
> 
> rhel-6 # grep Subsys /etc/ssh/sshd_config
> Subsystem sftp internal-sftp -l VERBOSE -f LOCAL6 -u 0777
> 
> rhel-6 # service sshd restart
> 
> client $ touch file; chmod 777 file
> 
> client $ sftp root@rhel-6
> Connected to rhel-6-preup.
> sftp> put file
> Uploading file to /root/file
> file                                         100%    0     0.0KB/s   00:00  
> 
> sftp> ls -l file
> ----------    0 0        0               0 Mar 12 12:40 file
> sftp> rm file
> Removing /root/file

I think this shows pretty well that it works fine the way it is.  Unless the OP can show something really is broken that we're missing, I second the motion to close this bug as "SEZWHO?"  OK, well WORKSFORME will do, I suppose.  :-)

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.