<div dir="ltr"><div dir="ltr">On Tue, Mar 8, 2022 at 7:15 AM Hove, K.W. van (Koen, Student M-CS) via rsync <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div>..wayne.. </div></div>