[LAU] OT: seeking help with uploading files via sftp and preventing their subsequent deletion

Erik Steffl erik at zasran.com
Fri Oct 10 20:05:07 UTC 2014


On 10/10/2014 12:51 PM, Ivica Ico Bukvic wrote:
> All,
>
> I am in a bit of a time-bind and am wondering if anyone could help me
> with this. Namely, I am trying to cobble a sftp system where conference
> participants may want to upload their proposed submissions and once they
> are uploaded that they are unable to delete their own or anyone else's
> submission. Going with commercial solutions is not an option.
>
> So, what I did so far is change /etc/ssh/sshd_config so that sftp
> chroots said user's home dir, and prevents access via ssh. I also
> created a sftponly group and added the user to it. I adjusted home dir
> permissions and created a subfolder "submissions" where users can submit
> their projects. Finally, I added umask to strip permissions from
> uploaded files.
>
> So, the /etc/ssh/sshd_config has the following entry
>
> Match Group sftponly
> ChrootDirectory /home/%u
> ForceCommand internal-sftp -u 0222
> X11Forwarding no
> AllowTcpForwarding no
>
> So, everything works, except no matter what permissions assign via
> umask, even if I change ownership manually via a different ssh user
> session, sftp client can still erase the file. How is this possible? And

   delete is an operation on directory, meaning they can delete file if 
they have write access to directory which they need to be able to create 
files.

> more importantly, how can one circumvent that? And perhaps most
> importantly is there an easier way to do this?

   seem like you can whitelist and blacklist sftp commands, so just 
don't allow delete? See man sftp and -p and -P options. Didn't actually 
try it but it seems like it would do what you want.

	erik

>
> Below are permissions of folders in question:
>
> drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
> drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
> drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
>
> Any idea how this can be fixed?
>



More information about the Linux-audio-user mailing list