Bug 859238 - Patch for openssh to implement internal-sftp with umask, chgrp, chown, and chmod.
Patch for openssh to implement internal-sftp with umask, chgrp, chown, and ch...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh (Show other bugs)
6.3
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Petr Lautrbach
BaseOS QE Security Team
:
Depends On:
Blocks: 994246 1056252
  Show dependency treegraph
 
Reported: 2012-09-20 17:08 EDT by jghobrial
Modified: 2015-08-21 18:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-13 10:27:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to implement sftpfilecontrol. (6.29 KB, application/x-compressed-tar)
2012-09-20 17:08 EDT, jghobrial
no flags Details

  None (edit)
Description jghobrial 2012-09-20 17:08:19 EDT
Created attachment 615126 [details]
Patch to implement sftpfilecontrol.

Patch for openssh to allow overriding umask, chown, chgrp, and chmod for internal-sftp. This patch applies cleanly to the below version and release and builds rpms.

Version-Release number of selected component (if applicable):
Version: 5.3p1
Release: 82.el6 

Modified 1.3 patch at http://sftpfilecontrol.sourceforge.net/

The reason I needed this was because the umask parameter exists for
Subsystem      sftp    /usr/libexec/openssh/sftp-server

but not for
Subsystem       sftp    internal-sftp

See Bug 657059 https://bugzilla.redhat.com/show_bug.cgi?id=657059

internal-sftp implements the ChrootDirectory, but sftp-server does not. I didn't want to build a complete chroot environment for each and every implementation.

Hope someone finds this useful.

Thanks,
Joseph
Comment 1 jghobrial 2012-09-20 17:10:08 EDT
Sorry, the Release number should have been 81.el6.
Comment 3 jghobrial 2012-09-20 17:13:57 EDT
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.
Comment 4 RHEL Product and Program Management 2012-12-14 03:10:40 EST
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.
Comment 9 Karel Srot 2014-03-11 03:08:24 EDT
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.
Comment 10 Petr Lautrbach 2014-03-12 07:48:31 EDT
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
Comment 11 Petr Lautrbach 2014-03-12 08:57:28 EDT
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
Comment 12 Thomas Gardner 2014-03-12 12:00:45 EDT
(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.  :-)
Comment 13 RHEL Product and Program Management 2014-03-13 10:27:05 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.