Bug 657059

Summary: Request to add umask capabilities to Openssh in RHEL
Product: Red Hat Enterprise Linux 6 Reporter: Mark Jones <mark.jones1>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: low    
Version: 6.1CC: mvadkert, sgrubb
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: openssh-5.3p1-33.el6 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:30:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mark Jones 2010-11-24 19:42:16 UTC
Description of problem:
Hi,
  I would like to request to add the umask feature to the openssh sftp subsystem.

It was implemented in openssh 5.4  

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 9 Miroslav Vadkerti 2011-03-09 09:57:11 UTC
First version of the Beaker test is ready. When using umask 0 the directories are created with expected permissions 777, but files are not created with good permissions. I think they should be created with permissions 666 if the copied file has no executable permissions:

:: [   PASS   ] :: Running 'sed -i 's/.*Subsystem.*sftp.*/Subsystem  sftp  \/usr\/libexec\/openssh\/sftp-server -u0/g' /etc/ssh/sshd_config'
:: [   PASS   ] :: Running '/usr/sbin/sshd -p9898'
:: [   PASS   ] :: Running 'touch test'
spawn sftp -o Port 9898 utest.englab.brq.redhat.com
Connecting to dell-pe1950-04.rhts.englab.brq.redhat.com...
utest.englab.brq.redhat.com's password: 
sftp> mkdir testdir
sftp> cd testdir
sftp> put test
Uploading test to /home/utest/testdir/test
test                                                                                                                                                                          100%    0     0.0KB/s   00:00    
sftp> bye
:: [   PASS   ] :: Running './sftp.exp utest utest 9898'
drwxrwxrwx. 2 utest utest 4096 Mar  9 04:44 /home/utest/testdir
:: [   PASS   ] :: Running 'ls -ld /home/utest/testdir | tee /tmp/tmp.ydSSYvzgIF'
:: [   PASS   ] :: File '/tmp/tmp.ydSSYvzgIF' should contain 'rwxrwxrwx'
-rw-r--r--. 1 utest utest 0 Mar  9 04:44 /home/utest/testdir/test
:: [   PASS   ] :: Running 'ls -l /home/utest/testdir/test | tee /tmp/tmp.ydSSYvzgIF'
:: [   FAIL   ] :: File '/tmp/tmp.ydSSYvzgIF' should contain 'rw-rw-rw-' 

As you can see the permissions are -rw-r--r-- instead of rw-rw-rw-

Comment 11 Miroslav Vadkerti 2011-03-09 14:30:48 UTC
Jan we need to find out if the test result in comment 9 is a bug. Moving to verified as it seems so

Comment 13 Miroslav Vadkerti 2011-03-15 12:53:47 UTC
The documentation doesn't mention that the umask should be entered as a decimal number:
-u umask  Sets an explicit umask(2) to be applied to newly-created files and directories, instead of the user’s default mask.


Also I think it should be possible to specify it as octal number as umask does this:
umask [-p] [-S] [mode]
              The user file-creation mask is set to mode.  If mode begins with
              a  digit,  it is interpreted as an octal number; ....


What do you say Jan?

Comment 14 Jan F. Chadima 2011-03-15 13:17:08 UTC
The documentation may be repaired, the change to the code may lead to regressions so I do not recommend it.

Comment 15 Steve Grubb 2011-03-15 13:27:14 UTC
Octal is the normal format when expressing file permissions and therefore the umask.

Comment 16 Miroslav Vadkerti 2011-03-15 17:03:08 UTC
Just for update: Jan found out that the umask octal format is already in upstream so the backport should be easy

Comment 17 Jan F. Chadima 2011-03-15 21:00:17 UTC
Updated to octal input format.

Comment 20 errata-xmlrpc 2011-05-19 13:30:49 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0598.html