That's the bug in this code - the dedupe length EOF rounding needs
to be more constrained as it's allowing an EOF block to be partially
matched against any full filesystem block as long as the range from
start to EOF in the block matches. That's the information leak right
there, and it has nothing to do with permissions.
Hence if we restrict EOF block deduping to both the src and dst
files having matching EOF offsets in their EOF blocks like so:
- if (pos_in + count == size_in) {
+ if (pos_in + count == size_in &&
+ (!(remap_flags & REMAP_FILE_DEDUP) || pos_out + count == size_out)) {
bcount = ALIGN(size_in, bs) - pos_in;
} else {
if (!IS_ALIGNED(count, bs))
count = ALIGN_DOWN(count, bs);
bcount = count;
}
This should fix the bug that was reported as it prevents dedupe an
EOF block against non-EOF blocks or even EOF blocks where EOF is at
a different offset into the EOF block.
So, yeah, I think arguing about permissions and API and all that
stuff is just going completely down the wrong track because it
doesn't actually address the root cause of the information leak....
I am sorry, while I do agree about the patch, I strongly disagree
regarding the permissions. Of course, this exact approach will not work
anymore in practice, since up to 2^^(4096*8) tries would be needed to
guess a single 4K block correctly.
Nevertheless it would be possible to guess the correct data for the
whole block, since a comparison of data is still possible. So if I want
to check whether a file contains a specific block (or one of a set) I
can still do so, without having read access.
Whether to keep this behavior to not break backwards compatibility is
not my decision, but the root problem of this leak is *not* about the
minimum block size that can be deduplicated, or that it can be lowered
by using the EOF behavior. It is about not needing read permissions to
compare data from a file.
Best regards,
Ansgar
--
M.Sc. Ansgar Lößer
Fachgebiet Kommunikationsnetze
Fachbereich für Elektrotechnik und Informationstechnik
Technische Universität Darmstadt
Rundeturmstraße 10
64283 Darmstadt
E-Mail: ansgar.loesser@xxxxxxxxxxxxxxxxxxx
http://www.kom.tu-darmstadt.de
