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

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@email-addr-hidden> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Oct 11 20:15:02 2014