For When You Can't Have The Real Thing
[ start | index | login ]
start > Linux > OpenSSH > sftp umask

sftp umask

Created by dave. Last edited by dave, 3 years and 266 days ago. Viewed 2,533 times. #3
[diff] [history] [edit] [rdf]
labels
attachments
(2015-03-26)

Problem

This is on a CentOS 6 system.

I want chroot'd sftp users to have a non-default umask.

In my case, I want "admin" users to be able to read and write content in "regular" users directories. This would give you a structure like:

sftproot
    |
    = user1
    |     |
    |     = user1
    = user2
    |     |
    |     = user2
    = (...)

Admin users would be chroot'd into sftproot. Regular users will be chrooted into sftproot/$username, and would see a directory with their name on it in that directory (because chroot directories have to be root:root 755).

Solution

I started by messing around with OpenSSH 5.8, and couldn't get it to work, although I have a good idea now why it wouldn't (see Gotchas, below).

I downloaded and built the latest openssh (which was 6.8) and built/installed that.

My relevant config is:

Subsystem       sftp    internal-sftp

Match Group sftponly ChrootDirectory %h ForceCommand internal-sftp -d %u -u 002

Gotcha

So what I struggled with for a long time is the fact that when you are coming from unix/Linux, the permissions on the source file matter. I had the umask set as 002, above, and my files kept getting uploaded to the remote server as 644. This is because the files on my local directory were created with umask 022, and therefore were 644 in my directory.

Once I set the permissions locally looser than 644, the umask worked.

Local Permissionssftp umaskRemote Permissions
644002644
664002664
666002664

It is quite possible that this was actually working in my first attempt, which was OpenSSH 5.9p1. It wasn't until I started messing with the local permissions that I had success.

When I sftp'd from Windows (which I didn't do initially under the operating theory that command line is always superior to the GUI, therefore if it doesn't work from the command line it won't work from the GUI) that the umask did what I expected it to do first time.

In any case, since I wanted the -d functionality I had to update to something newer than 5.9. I only picked 6.8 out of frustration because it was the most recent available at writing and should therefore be the most capable and least buggy.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt