Avatar of rspit
rspit
 asked on

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
LinuxSSH / Telnet SoftwareLinux Security

Avatar of undefined
Last Comment
rspit

8/22/2022 - Mon
rspit

ASKER
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.
woolmilkporc

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
woolmilkporc

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
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy
rspit

ASKER
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.
woolmilkporc

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
 
ASKER CERTIFIED SOLUTION
woolmilkporc

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
rspit

ASKER
Thank you
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.