Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix truncation of files upon read when using object store and encryption #28389

Merged
merged 2 commits into from
Oct 23, 2021
Merged

Fix truncation of files upon read when using object store and encryption #28389

merged 2 commits into from
Oct 23, 2021

Commits on Oct 23, 2021

  1. Fix truncation of files upon read when using object store and encrypt… 

    …ion.

When using and object store as primary storage and using the default
encryption module at the same time,  any encrypted file would be truncated
when read, and a text error message added to the end.

This was caused by a combination of the reliance of the read functions on
on knowing the unencrypted file size,  and a bug in the function which
calculated the unencrypted file size for a given file.

In order to calculate the unencrypted file size,  the function would first
skip the header block, then use fseek to skip to the last encrypted block
in the file.  Because there was a corresponence between the encrypted and
unencrypted blocks, this would also be the last encrypted block.  It would
then read the final block and decrypt it to get the unencrypted length of
the last block.  With that, the number of blocks, and the unencrypted block
size, it could calculate the unencrypted file size.

The trouble was that when using an object store, an fread call doesn't
always get you the number of bytes you asked for, even if they are
available.  To resolve this I adapted the stream_read_block function from
lib/private/Files/Streams/Encryption.php to work here.  This function
wraps the fread call in a loop and repeats until it has the entire set of
bytes that were requested,  or there are no more to get.

This fixes the imediate bug, and should (with luck) allow people to get
their encrypted files out of Nextcloud now.  (The problem was purely on
the decryption side).  In the future it would be nice to do some
refactoring here.

I have tested this with image files ranging from 1kb to 10mb using
Nextcloud version 22.1.0 (the nextcloud:22.1-apache docker image), with
sqlite and a Linode object store as the primary storage.

Signed-off-by: Alan Meeson <alan@carefullycalculated.co.uk>
    @alanmeeson
    alanmeeson committed Oct 23, 2021
    Configuration menu
    Copy the full SHA
    44c332a View commit details
    Browse the repository at this point in the history

  2. Add type hint to fread_block $blockSize param & apply cs:fix. 

    Signed-off-by: alanmeeson <alan@carefullycalculated.co.uk>
    @alanmeeson
    alanmeeson committed Oct 23, 2021
    Configuration menu
    Copy the full SHA
    16f70e8 View commit details
    Browse the repository at this point in the history