13

I know this question has been already discussed, but by reading the posts I could not figure the answers, because some said "yes umask can work", and others say "OpenSSH put command always preserve permissions"

Before all just to precise:

  • I use OpenSSH 5.9 on RHEL 6.2
  • I have configured a chrooted SFTP server, using internal-sftp subsystem, with -u 0002 for umask
  • I precise I don't use the -p or -P option

From what I have read on one hand: there are many ways to define umask for SFTP transfers:

  • option -u of internal-sftp (or sftp-server) , since OpenSSH 5.4
  • create a wrapper to sftp-server (in which we explicitly set the umask - this doesn't fit for chrooted environment btw)
  • add a specific configuration in pam.d/sshd file

On the other hand I have read:

The OpenSSH SFTP client and server do transfer the permissions (as an extension) and create the remote file with the permissions on the local side. AFAICT, there is no way to disable this behavior.

So I did the following test:

On my client I created file MYFILE and directory MYDIR with permissions 600 and 700.

Then with sftp commands:

mkdir => the new directory has permissions following the umask (OK)
put MYFILE => MYFILE has same permissions as on client (KO)
put -r MYDIR => MYDIR has same permissions as on client (KO)

If I change permissions of MYFILE and MYDIR on client side, and upload again, I get the new permissions on server side.

I tried the pam.d solution too, but it changed nothing.

So now I'm confused :

From what I tested and a part of what I read, I would say OpenSSH always preserve permissions. But as there are many posts saying that a umask could be defined, I can imagine I do a wrong thing in my test configurations.

I would appreciate some experienced feedback.

Thank you.

12

First, the umask is about the server not the client. So asking if put command of OpenSSH client uses umask is wrong. You should ask if OpenSSH server uses umask when creating a file as a result of SFTP upload.

Anyway, what OpenSSH SFTP client does:

  • put without -P flag, it asks the server to create a file with the same permissions as the local file has. The OpenSSH server then (implicitly by *nix rules) applies the umask.

  • put with the -P flag, it starts the same, but after the upload completes, the client asks the server to explicitly (re)set the permissions to the same the local file has ("chmod" request). For "chmod", the umask does not apply.

  • mkdir, it asks the server to create a directory with permissions 0777. The umask implicitly applies.

Anyway, I believe that umask 0002 has no effect on file with permissions 0600, as these are mutually exclusive. You should try your umask against a file with permissions like 0644.

So actually, it should work, if you have your system configured as you describe. See evidence from my box (Ubuntu with OpenSSH 6.2p2)

Match user user2
  ChrootDirectory /home/user2/chroot
  ForceCommand internal-sftp -u 0077
  AllowTcpForwarding no
  PermitTunnel no
  X11Forwarding no

See the difference in permissions after put vs. put -P:

user1:~$ touch file.txt
user1:~$ ls -l
total 0
-rw-r--r-- 1 user1 ftpuser    0 Oct 23 15:34 file.txt
user1:~$ sftp user2@localhost
user2@localhost's password: 
Connected to localhost.
sftp> cd somefolder 
sftp> put file.txt
Uploading file.txt to /somefolder/file.txt
file.txt                                         100%     0    0.0KB/s    0:00
sftp> ls -l
-rw-------    1 1003 1001    0 Oct 23 15:35 file.txt
sftp> put -P file.txt
Uploading file.txt to /somefolder/file.txt
file.txt                                         100%     0    0.0KB/s    0:00
sftp> ls -l
-rw-r--r--    1 1003 1001    0 Oct 23 15:34 file.txt

Btw, the latest SFTP specification defines behavior of the client and server regarding umask. As you can see, OpenSSH actually violates that, although the OpenSSH implements SFTP version 3 that had no mention of umask yet.

7.6. Permissions

...

The server SHOULD NOT apply a 'umask' to the mode bits; but should set the mode bits as specified by the client. The client MUST apply an appropriate 'umask' to the mode bits before sending them.

| improve this answer | |
  • I have already tried with many different permissions, at the very start I had 755 for my directory on client side, and wanted to get 775 instead. But it didn't work. I do agree with you for the -P by reading the documentation, but even without that flag I always get on server the same permissions than client (whatever permissions are) – drkmkzs Oct 23 '14 at 11:17
  • thanks for the remark, i tried to improve title and correct some term – drkmkzs Oct 23 '14 at 11:24
  • It should works actually, see my update. – Martin Prikryl Oct 23 '14 at 13:54
  • Yes, your example does work ... but if you change umask to 0002 it doesn't anymore. Maybe this post is raising the same problem ? except the fact I am in openssh5.9 and that umask option should work. The difference between with your SSHD configuration and mine is that I don't use ForceCommand, so I specify the umask in the subsystem line. (I'll try to post config and result, but the network test is not easily reachable) – drkmkzs Oct 23 '14 at 15:29
  • 1
    Just to be clear on that point: The server SHOULD NOT apply a 'umask' only applies when the client sends permission-information. When the client does not send permission-informations it is intended behavior to apply a umask! – heiglandreas Jun 1 '15 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.