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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
