<p dir="ltr">Thank you all for your responses. I finally opted for going the vsftpd route which has a much more finely grained approach to this.</p>
<div class="gmail_quote">On Oct 11, 2014 6:34 AM, "Tito Latini" <<a href="mailto:tito.01beta@gmail.com">tito.01beta@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 10, 2014 at 03:51:29PM -0400, Ivica Ico Bukvic wrote:<br>
> All,<br>
><br>
> I am in a bit of a time-bind and am wondering if anyone could help me<br>
> with this. Namely, I am trying to cobble a sftp system where conference<br>
> participants may want to upload their proposed submissions and once they<br>
> are uploaded that they are unable to delete their own or anyone else's<br>
> submission. Going with commercial solutions is not an option.<br>
><br>
> So, what I did so far is change /etc/ssh/sshd_config so that sftp<br>
> chroots said user's home dir, and prevents access via ssh. I also<br>
> created a sftponly group and added the user to it. I adjusted home dir<br>
> permissions and created a subfolder "submissions" where users can submit<br>
> their projects. Finally, I added umask to strip permissions from<br>
> uploaded files.<br>
><br>
> So, the /etc/ssh/sshd_config has the following entry<br>
><br>
> Match Group sftponly<br>
> ChrootDirectory /home/%u<br>
> ForceCommand internal-sftp -u 0222<br>
> X11Forwarding no<br>
> AllowTcpForwarding no<br>
><br>
> So, everything works, except no matter what permissions assign via<br>
> umask, even if I change ownership manually via a different ssh user<br>
> session, sftp client can still erase the file. How is this possible? And<br>
> more importantly, how can one circumvent that? And perhaps most<br>
> importantly is there an easier way to do this?<br>
><br>
> Below are permissions of folders in question:<br>
><br>
> drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .<br>
> drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..<br>
> drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions<br>
><br>
> Any idea how this can be fixed?<br>
<br>
An idea is to remove the destructive commands in sftp-server<br>
and open a file in write mode only with the file creation flags<br>
O_CREAT and O_EXCL, so it is impossible to overwrite a file.<br>
<br>
A patch (no tested) for sftp-server.c (openssh 6) is<br>
<br>
--- sftp-server.c~      2014-10-11 12:18:32.357980133 +0200<br>
+++ sftp-server.c       2014-10-11 12:18:32.357980133 +0200<br>
@@ -124,16 +124,14 @@<br>
<br>
        if ((pflags & SSH2_FXF_READ) &&<br>
            (pflags & SSH2_FXF_WRITE)) {<br>
-               flags = O_RDWR;<br>
+               flags = O_RDWR | O_CREAT | O_EXCL;<br>
        } else if (pflags & SSH2_FXF_READ) {<br>
                flags = O_RDONLY;<br>
        } else if (pflags & SSH2_FXF_WRITE) {<br>
-               flags = O_WRONLY;<br>
+               flags = O_WRONLY | O_CREAT | O_EXCL;<br>
        }<br>
        if (pflags & SSH2_FXF_CREAT)<br>
                flags |= O_CREAT;<br>
-       if (pflags & SSH2_FXF_TRUNC)<br>
-               flags |= O_TRUNC;<br>
        if (pflags & SSH2_FXF_EXCL)<br>
                flags |= O_EXCL;<br>
        return flags;<br>
@@ -1316,10 +1314,7 @@<br>
                process_fstat();<br>
                break;<br>
        case SSH2_FXP_SETSTAT:<br>
-               process_setstat();<br>
-               break;<br>
        case SSH2_FXP_FSETSTAT:<br>
-               process_fsetstat();<br>
                break;<br>
        case SSH2_FXP_OPENDIR:<br>
                process_opendir();<br>
@@ -1328,13 +1323,11 @@<br>
                process_readdir();<br>
                break;<br>
        case SSH2_FXP_REMOVE:<br>
-               process_remove();<br>
                break;<br>
        case SSH2_FXP_MKDIR:<br>
                process_mkdir();<br>
                break;<br>
        case SSH2_FXP_RMDIR:<br>
-               process_rmdir();<br>
                break;<br>
        case SSH2_FXP_REALPATH:<br>
                process_realpath();<br>
@@ -1343,7 +1336,6 @@<br>
                process_stat();<br>
                break;<br>
        case SSH2_FXP_RENAME:<br>
-               process_rename();<br>
                break;<br>
        case SSH2_FXP_READLINK:<br>
                process_readlink();<br>
@@ -1352,7 +1344,6 @@<br>
                process_symlink();<br>
                break;<br>
        case SSH2_FXP_EXTENDED:<br>
-               process_extended();<br>
                break;<br>
        default:<br>
                error("Unknown message %d", type);<br>
_______________________________________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org">Linux-audio-user@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-user" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-user</a><br>
</blockquote></div>