Re: [Proftpd-user] MOD_SFTP failing first upload attempt

I'd suggest a more concise error message might help others understand what
is happening.

In general it might be good to log a warning on startup informing those
operating the server that this combination of configuration options can
lead to undesirable situations.

On the other hand this is a very normal thing that has been around a very
long time. And present in many SFTP solutions at least those used in
Enterprise settings. There are clients that handle this by first creating
the file and then setting permissions after the upload completes to
circumvent such issues, I believe that for instance WinSCP can be made to
attempt to set permissions only after upload.

On Sat, Jul 2, 2022, 23:52 TJ Saunders <[email protected]> wrote:

> >> But after 3 days of googling around, I was kind of convinced as well
> >> that is was an SFTP issue, and I found the fix on the documentation
> >> page of mod_sftp:
> >> http://proftpd.org/docs/contrib/mod_sftp.html#SFTPOptions
> >>
> >> This is what had to be added to make it work:
> >> ubuntu@FTP-PROD1:~$ cat /opt/proftpd-sftp/etc/proftpd.conf | grep
> SFTPOption
> >> *SFTPOptions IgnoreSFTPUploadPerms*
> >>
> >> Seems like sftp client on linux is using some kind of Upload
> >> permissions and that gives that Permission denied results.
>
> I did a little more research into this particular scenario, and I better
> understand now why you were seeing the behavior that you were seeing (i.e.
> a second upload, with all the same parameters, succeeds where the first
> upload did not), and why using the IgnoreSFTPUploadPerms option "fixed"
> things.
>
> When your SFTP client attempted the first upload, the destination file did
> not exist on the server.  So mod_sftp first created the file, and then
> attempted to process the additional permission information in that SFTP
> OPEN request.  For OpenSSH, it attempts to set the permissions to be 777 on
> the file.  It was the setting of these 777 permissions on the newly created
> file which failed with "Permission denied".  And that happened because your
> ProFTPD configuration included this:
>
>   <Limit SITE_CHMOD>
>     DenyAll
>   </Limit>
>
> The mod_sftp module tries to honor all the same configurations, for SFTP
> sessions, as is done for FTP sessions; this includes checking for such
> <Limit> sections, and denying them where relevant.  The setting of
> permissions on SFTP uploads is blocked by the above <Limit>, as might be
> expected.
>
> So now the SFTP client attempts the upload again.  This is where things
> get interesting, because this time, the destination file _does_ exist on
> the server.  Why does this matter?  Turns out that in mod_sftp, if the
> upload file already exists, then we _ignore_ any permissions requested by
> the client (assuming that the existing file permissions are the desirable
> ones) -- and thus we do not run into the <Limit SITE_CHMOD> restriction,
> and the upload succeeds.
>
> This is an interesting combination of factors, and I'm not sure what
> changes we might do, to help future folks who may encounter this unexpected
> behavior.  Any suggestions?
>
> Cheers,
> TJ
>
>
> _______________________________________________
> ProFTPD Users List   <[email protected]>
> Unsubscribe problems?
> http://www.proftpd.org/list-unsub.html
>

_______________________________________________
ProFTPD Users List   <[email protected]>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html