Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2047
  • Last Modified:

UMask settings in Ubuntu SFTP Server are ignored

We have built an SFTP server with OpenSSH which has local Linux user accounts as well as PAM based Active Directory accounts. We will use this SFTP server for our customers (the local linux user) to share files with our employees (who login with their Active Directory account). We have CHRooted every local linux user and an Active Directory group to a  specific folder (the client’s folder). We use "internal-sftp" mode. The problem is when a client uses the “SFTP” application to upload files, our Active Directory based employees cannot open the files. We have to run CHMod each time. The umask settings we have established are not used.

We don't have this issue if the customer uses another client other than SFTP (such as FileZilla). However, we cannot force our client to use another application

Details:
1 - Customer upload some files to our SFTP server, below are the files I want to upload:
[root@CLIENT]# ls -l
total 12
-rw------- 1 root root 12 Mar  9 16:13 2.txt   //only root can read and write to this file

Uploading file
[root@nagios test]# sftp test@SFTP-test
Connecting to SFTP-Test
Password:
sftp> ls
Submission
sftp> cd Submission
sftp> put 2.txt
Uploading 2.txt to /Client/Submission/2.txt
2.txt                                         100%   12     0.0KB/s   00:00    
sftp> ls -l   //after upload the file the file permission keeps unchanged in our SFTP server. Only the user who uploads files can access it.
-rw-------    1 1505     1001           12 Mar  9 09:55 2.txt

2 - If our employee wants to access this file, the file permission should be -rw----r--
4 - In Linux system, we use umask to define the default permission for creating a new file.
         example: umask = 022, when we create a file, the file permission is -rw-r--r--(644)

*** SFTP Configuration (Cleansed of confidential) ***


# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2


#Privilege Separation is turned on for security UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

# Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) #Overwritten by lwidentity: ChallengeResponseAuthentication no ChallengeResponseAuthentication yes

# Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables AcceptEnv LANG LC_*

Subsystem sftp internal-sftp

UsePAM yes
KbdInteractiveAuthentication yes

Match group group1
        ChrootDirectory /home/ftp/group1
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp
0
rspit
Asked:
rspit
  • 4
  • 3
1 Solution
 
rspitAuthor Commented:
We have updated to the latest OpenSSH version in Ubuntu as we understood there were previous issues with umask being ignored. However, in the latest version we understand that umask now works. It doesnt work for us still.
0
 
woolmilkporcCommented:
Hi,

is your new openssh version 5.4p1 or higher?

Starting with this version internal-sftp supports setting a decimal (!) umask via command line.

If you have 5.4p1 or higher use

ForceCommand  internal-sftp  -u 18

since octal "022" is decimal "18".

Don't forget to restart the ssh daemon!

NOTE: You cannot use the umask on sftp to change the permission on a file
to be less restrictive than the original file!

wmp
0
 
woolmilkporcCommented:
Rereading your Q - my last NOTE above seems the key to your issue:

You cannot use the umask on sftp to change the permission on a file
to be less restrictive than the original file!


So issue chmod before uploading!

If this isn't possible a cronjob on the target system to update permissions via chmod regularly could do the trick!

wmp
0
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

 
rspitAuthor Commented:
We cannot force our customers to issue a chmod before uploading. Is there any way to issue a script to do a chmod from the server for all newly uploaded files? I'd prefer not to have a script on a cronjob as there would be a delay in when the files are available.
0
 
woolmilkporcCommented:
OK, several remarks:

1) The files in question must have been created on the source server(s) some way. Could it be an option to configure an appropriate umask for the user/process creating the file?

2) Why not cron? You could run the job every minute, causing a rather short delay.

3) If you can't force the users to run a chmod command before transferring, why should you be able to force them to run a script/command on the target server afterwards?

4) Do your customers use a script for uploading? If so, it should be easy to integrate a permissions change there, either via the subcommand "chmod" of sftp, or before uploading via shell command "chmod" or afterwards (via ssh + shell command to the target server).

5) If all this is not an option consider using "inotifywait" on the target server.

A script could look like this:

#!/bin/sh
  while inotifywait -e create /path/to/upload/directory; do
          chmod 644 %f
  done

Run it in background with nohup.
Consider autostarting it at reboot.

wmp
 
0
 
woolmilkporcCommented:
Sorry, forgot a part of the script!

#!/bin/sh
  while f=$(inotifywait -e create --format "%f" /path/to/upload/directory) ; do
          chmod 644 $f
  done
0
 
rspitAuthor Commented:
Thank you
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now