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

Ivica Bukvic ico at vt.edu
Sat Oct 11 14:14:31 UTC 2014


Thank you all for your responses. I finally opted for going the vsftpd
route which has a much more finely grained approach to this.
On Oct 11, 2014 6:34 AM, "Tito Latini" <tito.01beta at gmail.com> wrote:

> On Fri, Oct 10, 2014 at 03:51:29PM -0400, 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
> > more importantly, how can one circumvent that? And perhaps most
> > importantly is there an easier way to do this?
> >
> > 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?
>
> An idea is to remove the destructive commands in sftp-server
> and open a file in write mode only with the file creation flags
> O_CREAT and O_EXCL, so it is impossible to overwrite a file.
>
> A patch (no tested) for sftp-server.c (openssh 6) is
>
> --- sftp-server.c~      2014-10-11 12:18:32.357980133 +0200
> +++ sftp-server.c       2014-10-11 12:18:32.357980133 +0200
> @@ -124,16 +124,14 @@
>
>         if ((pflags & SSH2_FXF_READ) &&
>             (pflags & SSH2_FXF_WRITE)) {
> -               flags = O_RDWR;
> +               flags = O_RDWR | O_CREAT | O_EXCL;
>         } else if (pflags & SSH2_FXF_READ) {
>                 flags = O_RDONLY;
>         } else if (pflags & SSH2_FXF_WRITE) {
> -               flags = O_WRONLY;
> +               flags = O_WRONLY | O_CREAT | O_EXCL;
>         }
>         if (pflags & SSH2_FXF_CREAT)
>                 flags |= O_CREAT;
> -       if (pflags & SSH2_FXF_TRUNC)
> -               flags |= O_TRUNC;
>         if (pflags & SSH2_FXF_EXCL)
>                 flags |= O_EXCL;
>         return flags;
> @@ -1316,10 +1314,7 @@
>                 process_fstat();
>                 break;
>         case SSH2_FXP_SETSTAT:
> -               process_setstat();
> -               break;
>         case SSH2_FXP_FSETSTAT:
> -               process_fsetstat();
>                 break;
>         case SSH2_FXP_OPENDIR:
>                 process_opendir();
> @@ -1328,13 +1323,11 @@
>                 process_readdir();
>                 break;
>         case SSH2_FXP_REMOVE:
> -               process_remove();
>                 break;
>         case SSH2_FXP_MKDIR:
>                 process_mkdir();
>                 break;
>         case SSH2_FXP_RMDIR:
> -               process_rmdir();
>                 break;
>         case SSH2_FXP_REALPATH:
>                 process_realpath();
> @@ -1343,7 +1336,6 @@
>                 process_stat();
>                 break;
>         case SSH2_FXP_RENAME:
> -               process_rename();
>                 break;
>         case SSH2_FXP_READLINK:
>                 process_readlink();
> @@ -1352,7 +1344,6 @@
>                 process_symlink();
>                 break;
>         case SSH2_FXP_EXTENDED:
> -               process_extended();
>                 break;
>         default:
>                 error("Unknown message %d", type);
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20141011/314547c6/attachment.html>


More information about the Linux-audio-user mailing list