[Security issue] Owner and Group are not preserved

Expected behaviour: If a remote file exists, and I upload or sync to the server a local file with same filename then the Owner and Group of the remote file should be preserved.

Actual behaviour: The expected behaviour is seen only for files that are under the size limit set in Transfer > Endurance > 'Enable transfer resume/transfer to temporary filename for'. Any files that exceed that size limit lose the original Owner and Group (they are not preserved). Interestingly, the original file permissions ARE preserved.

Workaround until this is fixed:
Set Transfer > Endurance > 'Enable transfer resume/transfer to temporary filename for' to 'Disable'.

Tested with:

• WinSCP 5.2.1 (Build 3231) and with older versions too (even 4.x.x) in SFTP-3 mode.
  
• Remote server is Debian 6
  
• Local server is Windows 7 SP1
  

Thanks for your report. This is documented here:
https://winscp.net/eng/docs/resume#automatic

There's an explicit code to "copy" the permissions from original files to the new one. While it can possibly also "copy" the group, it cannot copy owner as you would have to be logged in as a root to do that.

Added to tracker:
Issue 1003 – Preserve owning group when uploading file to temporary file name

Hi, Even though it is documented somewhere, the behavious is completely unexpected and dangerous as it creates severe security issues that are hard to notice. So thank you for creating a bug for it.

Regards,

Also, the fact that file permissions ARE preserved, while group/owner aren't, qualifies this as a clear bug (not a documented behaviour).

The bug subject in the bugtracker item states that only Group is not preserved, but it is also the Owner that is not preserved. Both are equally important.

I had the same issue. My code would not work any more after some uploads. I noticed that the ownership of some files changed after every upload. I applied the work around and it does not do that anymore. Thanks. I don't give myself root permission, exactly because I do not want to mess with ownership. It is strange that WinSCP can even do that. It requires root permission and I don't provide the required ROOT credential.

Dominic wrote:

It is strange that WinSCP can even do that. It requires root permission and I don't provide the required ROOT credential.

You do not need root permissions to delete a file and create new one with the same name, but an ownership of logged-in user.

@martin: OK, I did not think very far when I wrote this extra point. Still for most files, the observed result is that the original (group) ownership is preserved. Only in special cases, the (group) ownership is changed. The documentation that you mentioned says nothing about (group) ownership. If we know about this other documented behavior, we can see the connection, but that does NOT make this special (group) ownership behavior a documented behavior. It is NOT a documented behavior, but if it was, I would consider this even worst. Who in is right mind would want such a behavior ?

@martin: OK, I understand that, if it deletes a file and creates a new one with the same name, WinSCP has no other choice than to use the logged-in user ownership. This is NOT documented, but it is an understandable behavior. However, in my case I was the owner and in the group of the original file in the server. Is there a reason why the group ownership is not preserved? At the end, I just want a simple uniform behavior, independent of other configurations and special file properties such as its size.

It's a Unix/Linux limitation...

Quoting https://en.wikipedia.org/wiki/Chown :

Unprivileged (regular) users who wish to change the group of a file that they own may use chgrp.

For obvious security reasons, the ownership of a file may only be altered by a super-user. Similarly, only a member of a group can change a file's group ID to that group.

OK, I did not think very far when I wrote this extra point. Still for most files, the observed result is that the original (group) ownership is preserved. Only in special cases, the (group) ownership is changed. The documentation that you mentioned says nothing about (group) ownership. If we know about this other documented behavior, we can see the connection, but that does NOT make this special (group) ownership behavior a documented behavior. It is NOT a documented behavior, but if it was, I would consider this even worst. Who in is right mind would want such a behavior ?

It's not a desired behavior, but rather a side-effect of desired behavior.
I believe that both the side-effect and reason WinSCP does that (transfer via temporary directory) is well documented on page below (already linked earlier in this topic):
https://winscp.net/eng/docs/resume#automatic

This issue has been added to the tracker:
Issue 1260 – Never doing transfer via temporary file when overwriting a file known to be owned by another user

I don't fully understand how SFTP work. Been trying to find an easy explanation for a while but not found any.

Since background transfer is always opening new SSH connection, can you do it like this?

1. open connection
   
2. start SFTP server binary
   
3. upload all queued file to temporary and keep a mapping of temp -> orig
   
4. exit SFTP server
   
5. use dd or cat to overwrite file, eg: cat temp > orig
   
6. sleep. if there is new queue, go back to step 2
   

@gabri.ns: Thanks for your suggestion. Though that's not SFTP solution anymore. It's not portable.

It's really annoying cause it does it to seemingly random files, and the website I'm working on breaks on those files when the owner is no longer correct.

@martin: What about this?

1. COPY A B
   
2. RENAME A.partial
   
3. RENAME B A
   
4. TRUNCATE/RESUME A.partial
   
5. DELETE A
   
6. RENAME A.partial A
   

Is this operation primitive enough to be portable?

And i think this will also help catch this problem early on step 4

If the target file exists and it is not write-able, but the target directory is, the file will may be transferred anyway with automatic resume. The error overwriting the file will occur only after the transfer finishes. It is because the file is first transferred into temporary file.

And abort accordingly by reverting previous operation.

@gabri.ns: Sorry, but I'm lost. What are "A" and "B"?