[gnome-remote-desktop] rdp-fuse-clipboard: Read files until the very end

[Jonas Ådahl <jadahl src gnome org>]

commit 7df0fcb46bd5785ff0435a6e10aabd41cfa19e16
Author: Pascal Nowack <Pascal Nowack gmx de>
Date:   Sun Apr 11 15:32:45 2021 +0200

    rdp-fuse-clipboard: Read files until the very end
    
    Currently, gnome-remote-desktop truncates the requested file size to
    the actual size of the requested file.
    While this action is protocol-wise completely fine, it causes a serious
    issue with mstsc and also did with xfreerdp in the past:
    
    Until recently, FreeRDP had a bug ([1]), where xfreerdp opened a FD to
    read the file contents, closed the FD, when the transfer of the file
    was complete and opened the FD again on the last (zero-sized) request,
    but never closed the FD again.
    The result was that, when copying over a thousand files, the
    transmission will eventually fail, since xfreerdp runs out of open FDs.
    The bug is now fixed on FreeRDPs master, but old clients will still run
    into this issue (without this commit).
    
    mstsc has a similar bug: However, it is way nastier:
    When transferring files with mstsc, gnome-remote-desktop (and any other
    server too) needs to read the file until mstsc returns the size 0.
    If gnome-remote-desktop stops earlier (, while still reading the
    complete file, but not requesting the non-existing last byte(s)) or
    requests a zero-sized part at the end, mstsc will fail.
    It fails in either two ways: Either mstsc silently fails by not
    responding to the file requests (leaving g-r-d in the rain) or it fails
    in a really nasty way by responding with corrupt data.
    Corrupt data means, the whole PDU is corrupt.
    FreeRDP notices that and puts out an error like this:
    "Unexpected clipboard PDU type: 62048"
    After this error, FreeRDP immediately stops the cliprdr thread to
    prevent any damage.
    
    This issue might not even just be a protocol violation, but maybe also
    a serious security issue (CVE) in mstsc.
    It is, however, pointless to report this to Microsoft. They won't fix
    it anyway, unless Google makes the issue public (it was also the case
    in the past with other way more problematic issues).
    
    Both cases are (were in the case of FreeRDP) issues on the client side.
    However, gnome-remote-desktop can work around them by not truncating
    the requested size.
    The FUSE backend already reads a file until it receives a zero-sized
    buffer as response, so the only the thing that gnome-remote-desktop
    needs to do is to not truncate files to zero any more.
    The size to request can still be truncated to prevent massive requests,
    but not to zero any more.
    
    So, remove the truncate handling, except the parts, where huge file
    requests are truncated to smaller ones, to ensure that both old
    xfreerdp versions and mstsc always work fine.
    gnome-remote-desktop cannot fix these client side issues, only work
    around them.
    
    [1]: https://github.com/FreeRDP/FreeRDP/pull/6924

 src/grd-rdp-fuse-clipboard.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
---
diff --git a/src/grd-rdp-fuse-clipboard.c b/src/grd-rdp-fuse-clipboard.c
index 10c5910..3101c32 100644
--- a/src/grd-rdp-fuse-clipboard.c
+++ b/src/grd-rdp-fuse-clipboard.c
@@ -703,7 +703,9 @@ fuse_ll_read (fuse_req_t             fuse_req,
       return;
     }
 
-  size = MIN (MIN (size, 8 * 1024 * 1024), fuse_file->size - offset);
+  size = MIN (size, 8 * 1024 * 1024);
+  g_assert (size > 0);
+
   request_file_range_async (rdp_fuse_clipboard, fuse_file, fuse_req,
                             offset, size);
   g_mutex_unlock (&rdp_fuse_clipboard->filesystem_mutex);