Re: Is there a better way to transfer data that doesn't use so much cache?

[Wayne Davison via rsync]

On Wed, Aug 3, 2022 at 7:10 PM Dan Stromberg wrote:

> However, if you transfer a large amount of data and do not intend to
> retransmit that data any time soon, then the memory isn't really put to
> good use, and can actually cause your system to slow down significantly -
> particularly if there's a lot of such data transferred.
>

I have always rejected overcomplicating rsync with cache control code (the
complexity of a --drop-cache patch I saw was quite horrifying).  In the
past I pointed people towards https://github.com/Feh/nocache as one way to
get posix_fadvise used by an rsync copy.  That project now apparently
suggests creating a memory-bounded cgroup, which sounds interesting.

..wayne..
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Restriction enforcement

[Hove, K.W. van (Koen, Student M-CS) via rsync]

Dear Wayne, all,

I recently saw the report from OpenWall on CVE-2022-29154 as well as the 
prerelease of rsync 3.2.5. I believe that is the same issue (albeit with a 
malicious scenario attached to it), right? If so, I am happy to see it 
resolved. 

Cordially,
Koen van Hove

From: Wayne Davison 
Date: Saturday, 12 March 2022 at 18:20
To: "Hove, K.W. van (Koen, Student M-CS)" 
Cc: "rsync@lists.samba.org" 
Subject: Re: Restriction enforcement

On Tue, Mar 8, 2022 at 7:15 AM Hove, K.W. van (Koen, Student M-CS) via rsync 
 wrote:
I noticed that --max-size, --min-size, --exclude, and --include are only sent 
by the client as a "request" to the server, and that if the server for some 
reason chooses to ignore those options and include those files in the file list 
anyway, the client will happily run with it.

That is not based on client & server but rather sender & receiver. The sender 
gets the filter (include/exclude) commands so that it can trim the list it 
sends, but the client uses the min/max size values to figure out which files it 
wants to request. The client only uses the filter rules if it is running 
deletion commands. The daemon has a bit more paranoia, with an extra filter 
list that is consulted on both the sending & receiving side. So, one simple 
change that could be done would be to tweak generator.c & receiver.c and add in 
filter checks of the main filter_list where it is checking the 
daemon_filter_list.

So, for the most part, rsync expects each side to do their job and doesn't 
double-check non-security things (it does security-check that the file list 
hasn't gone outside the request's bounds and that it doesn't leverage a symlink 
as a way to escape the hierarchy, for instance).  There is also the problem 
that the generator has no direct way to tell the receiver what it is doing 
(given the big loop of information from generator to sender to receiver) so a 
rogue sender could be written to send files that the generator didn't request.

..wayne.. 

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html