The permission check in vfs_dedupe_file_range() is too coarse - We only allow dedupe of the destination file if the user is root, or they have the file open for write.
This effectively limits a non-root user from deduping their own read-only files. As file data during a dedupe does not change, this is unexpected behavior and this has caused a number of issue reports. For an example, see: https://github.com/markfasheh/duperemove/issues/129 So change the check so we allow dedupe on the target if: - the root or admin is asking for it - the owner of the file is asking for the dedupe - the process has write access Signed-off-by: Mark Fasheh <mfas...@suse.de> --- fs/read_write.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index c4eabbfc90df..77986a2e2a3b 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -2036,7 +2036,8 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same) if (info->reserved) { info->status = -EINVAL; - } else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE))) { + } else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) || + uid_eq(current_fsuid(), dst->i_uid))) { info->status = -EINVAL; } else if (file->f_path.mnt != dst_file->f_path.mnt) { info->status = -EXDEV; -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
