[Security issue] Owner and Group are not preserved

Advertisement

pvalnov
Joined:
Posts:
1

[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

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
41,431
Location:
Prague, Czechia

Re: [Security issue] Owner and Group are not preserved

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

Reply with quote

Guest

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,

Reply with quote

Guest

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

Reply with quote

Guest

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.

Reply with quote

Advertisement

Dominic
Guest

Thank you to have reported this bug

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.

Reply with quote

martin
Site Admin
martin avatar

Re: Thank you to have reported this bug

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.

Reply with quote

Guest

Re: Thank you to have reported this bug

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

Reply with quote

Guest

Re: Thank you to have reported this bug

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

Reply with quote

Advertisement

Ricardo
Donor
Ricardo avatar
Joined:
Posts:
107

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.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,431
Location:
Prague, Czechia

Re: Thank you to have reported this bug

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

Reply with quote

gabri.ns
Joined:
Posts:
8

workaround suggestion

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

Reply with quote

Advertisement

Guest

Still getting the error in 2018

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.

Reply with quote

gabri.ns
Joined:
Posts:
8

Re: workaround suggestion

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

Reply with quote

Advertisement

You can post new topics in this forum