3

I have the following setup:

  • Ubuntu 14.4 server offering SFTP service in a front-end area.
  • External clients have the ability to upload files.
  • A back-end process (on another server) tracks uploaded files, triggers some back-end tasks and modifies the files back according to the outcome of the tasks.

SFTP users have ownership of the files they upload. SFTP users and back-end process are members of the same group. With a umask of 0007, back-end process can access and modify these files.

However, some users upload files with 600'ish rights, making the back-end process unable to handle these files.

There are plenty of ways to restrict rights (umask, acl) but I could not find a way to automatically grant group access to files uploaded with too restrictive rights.

Is there a way to automatically transform files uploaded with 600 or 640 rights to 660?

  • I could not understand where is your problem, what is preventing you to run chmod 660 filename in the back-end? – Kira Oct 22 '15 at 15:26
  • 1
    @Kira The backend doesn't own the files and doesn't run as root. If it was allowed to change the permissions of the files, that would completely defeat any security brought by file permissions. – Gilles Oct 22 '15 at 18:50
3

This is common ever-green for sftp. From SuperUser:

Background

This is ever lasting problem of sftp and sharing files. It is because of the resulting permissions are based on the original permission of the file on the user side and umask (-u) argument is not forcing such permissions, but only stripping the unwanted permissions. This means that only if user tries to upload file with permission 0777, it is applied and stripped down to 0775. Otherwise it is just left as it was. For example if the user has file stored on his file system with permission 0700, it will appear also after upload as 0700.

Solution

Recently we solved this issue in Fedora by applying patch which is forcing exact permission of new uploaded files, which is based on this one:

https://bugzilla.mindrot.org/show_bug.cgi?id=1844

This will be available in CentOS in few months, not sure about debian.

Workaround

There is no other elegant solution except some periodical running script (from cron), which is fixing the wrong permissions. It would be some one-liner in bash, but I guess you can think of some. I can elaborate on this more if you are interested.

Debian?

For debian-based systems, there is probably workaround using bindfs: Basically it mounts one directory into another and you can force all permissions to behave however you like.

  • Thanks for the info. The cron workaround is unfortunately not an option for me since it introduces a too high rick for racing condition: I can't cron(tab) anything more frequently that 1 minute, the chances are too high that the back-end job will notice new files before a cron job fixes the group right issue. The bindfs sounds overkill to me. As you can see below, I went for iwatch that has the ability to fix the rights instantly after a file has been uploaded. – Olivier Dauby Oct 24 '15 at 12:37
2

Ok, I finally used iwatch.

/etc/default/iwatch:

START_DAEMON=true
CONFIG_FILE=/etc/iwatch/iwatch.xml

/etc/iwatch/iwatch.xml:

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "/etc/iwatch/iwatch.dtd" >

<config>
  <guard email="" name=""/>
  <watchlist>
    <title>Fix SFTP rights of uploaded files -- grant group access</title>
    <contactpoint email="" name=""/>
    <path type="recursive" alert="off" exec="chmod g+rw %f" events="close_write">/home/sftpusers</path>
  </watchlist>
</config>

Where /home/sftpusers is the place where sftp users have their home directories.

This way, each time a file has been uploaded (close_write triggered) by an sftp user, it gets instantly a chmod g+rw treatment.

This fixed my issue pretty well.

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.