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

>> 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