* [PATCH v6 0/2] vfs: fix dedupe permission check
@ 2018-09-10 23:21 Mark Fasheh
2018-09-10 23:21 ` [PATCH 1/2] vfs: allow dedupe of user owned read-only files Mark Fasheh
2018-09-10 23:21 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
0 siblings, 2 replies; 3+ messages in thread
From: Mark Fasheh @ 2018-09-10 23:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Al Viro, linux-fsdevel, linux-api, Michael Kerrisk, linux-btrfs,
linux-xfs, Darrick J . Wong, Adam Borowski, David Sterba,
Mark Fasheh
Hi Andrew/Al,
Could I please have these patches put in a tree for more public testing?
They've hit fsdevel a few times now, I have links to the discussions in the
change log below.
The following patches fix a couple of issues with the permission check
we do in vfs_dedupe_file_range().
The first patch expands our check to allow dedupe of a file if the
user owns it or otherwise would be allowed to write to it.
Current behavior is that we'll allow dedupe only if:
- the user is an admin (root)
- the user has the file open for write
This makes it impossible for a user to dedupe their own file set
unless they do it as root, or ensure that all files have write
permission. There's a couple of duperemove bugs open for this:
https://github.com/markfasheh/duperemove/issues/129
https://github.com/markfasheh/duperemove/issues/86
The other problem we have is also related to forcing the user to open
target files for write - A process trying to exec a file currently
being deduped gets ETXTBUSY. The answer (as above) is to allow them to
open the targets ro - root can already do this. There was a patch from
Adam Borowski to fix this back in 2016:
https://lkml.org/lkml/2016/7/17/130
which I have incorporated into my changes.
The 2nd patch fixes our return code for permission denied to be
EPERM. For some reason we're returning EINVAL - I think that's
probably my fault. At any rate, we need to be returning something
descriptive of the actual problem, otherwise callers see EINVAL and
can't really make a valid determination of what's gone wrong.
This has also popped up in duperemove, mostly in the form of cryptic
error messages. Because this is a code returned to userspace, I did
check the other users of extent-same that I could find. Both 'bees'
and 'rust-btrfs' do the same as duperemove and simply report the error
(as they should).
One way I tested these patches was to make non-root owned files with
read-only permissions and see if I could dedupe them as the owning user. For
example, the following script fails on an unpatched kernel and succeeds with
the patches applied.
TESTDIR=/btrfs
USER=mfasheh
rm -f $TESTDIR/file*
dd if=/dev/zero of=$TESTDIR/file1 count=1024 bs=1024
dd if=/dev/zero of=$TESTDIR/file2 count=1024 bs=1024
chown $USER $TESTDIR/file*
chmod 444 $TESTDIR/file*
# open file* for read and dedupe
sudo -u $USER duperemove -Ad $TESTDIR/file*
Lastly, I have an update to the fi_deduperange manpage to reflect these
changes. That patch is attached below.
git pull https://github.com/markfasheh/linux dedupe-perms
Thanks,
--Mark
Changes from V5 to V6:
- Rebase and retest on 4.19-rc3
- Add a note on testing
Changes from V4 to V5:
- Rebase and retest on 4.18-rc8
- Place updated manpage patch below, CC linux-api
- V4 discussion: https://patchwork.kernel.org/patch/10530365/
Changes from V3 to V4:
- Add a patch (below) to ioctl_fideduperange.2 explaining our
changes. I will send this patch once the kernel update is
accepted. Thanks to Darrick Wong for this suggestion.
- V3 discussion: https://www.spinics.net/lists/linux-btrfs/msg79135.html
Changes from V2 to V3:
- Return bool from allow_file_dedupe
- V2 discussion: https://www.spinics.net/lists/linux-btrfs/msg78421.html
Changes from V1 to V2:
- Add inode_permission check as suggested by Adam Borowski
- V1 discussion: https://marc.info/?l=linux-xfs&m=152606684017965&w=2
From: Mark Fasheh <mfasheh@suse.de>
[PATCH] ioctl_fideduperange.2: clarify permission requirements
dedupe permission checks were recently relaxed - update our man page to
reflect those changes.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
---
man2/ioctl_fideduperange.2 | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/man2/ioctl_fideduperange.2 b/man2/ioctl_fideduperange.2
index 84d20a276..4040ee064 100644
--- a/man2/ioctl_fideduperange.2
+++ b/man2/ioctl_fideduperange.2
@@ -105,9 +105,12 @@ The field
must be zero.
During the call,
.IR src_fd
-must be open for reading and
+must be open for reading.
.IR dest_fd
-must be open for writing.
+can be open for writing, or reading.
+If
+.IR dest_fd
+is open for reading, the user must have write access to the file.
The combined size of the struct
.IR file_dedupe_range
and the struct
@@ -185,8 +188,8 @@ This can appear if the filesystem does not support deduplicating either file
descriptor, or if either file descriptor refers to special inodes.
.TP
.B EPERM
-.IR dest_fd
-is immutable.
+This will be returned if the user lacks permission to dedupe the file referenced by
+.IR dest_fd .
.TP
.B ETXTBSY
One of the files is a swap file.
--
2.15.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH 1/2] vfs: allow dedupe of user owned read-only files
2018-09-10 23:21 [PATCH v6 0/2] vfs: fix dedupe permission check Mark Fasheh
@ 2018-09-10 23:21 ` Mark Fasheh
2018-09-10 23:21 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
1 sibling, 0 replies; 3+ messages in thread
From: Mark Fasheh @ 2018-09-10 23:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Al Viro, linux-fsdevel, linux-api, Michael Kerrisk, linux-btrfs,
linux-xfs, Darrick J . Wong, Adam Borowski, David Sterba,
Mark Fasheh
The permission check in vfs_dedupe_file_range_one() 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. In addition, the write file descriptor that the user is forced to
hold open can prevent execution of files. As file data during a dedupe
does not change, the behavior is unexpected 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 process has write access
- the owner of the file is asking for the dedupe
- the process could get write access
That way users can open read-only and still get dedupe.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
---
fs/read_write.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 39b4a21dd933..be0e8723a049 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1964,6 +1964,20 @@ int vfs_dedupe_file_range_compare(struct inode *src, loff_t srcoff,
}
EXPORT_SYMBOL(vfs_dedupe_file_range_compare);
+/* Check whether we are allowed to dedupe the destination file */
+static bool allow_file_dedupe(struct file *file)
+{
+ if (capable(CAP_SYS_ADMIN))
+ return true;
+ if (file->f_mode & FMODE_WRITE)
+ return true;
+ if (uid_eq(current_fsuid(), file_inode(file)->i_uid))
+ return true;
+ if (!inode_permission(file_inode(file), MAY_WRITE))
+ return true;
+ return false;
+}
+
int vfs_dedupe_file_range_one(struct file *src_file, loff_t src_pos,
struct file *dst_file, loff_t dst_pos, u64 len)
{
@@ -1978,7 +1992,7 @@ int vfs_dedupe_file_range_one(struct file *src_file, loff_t src_pos,
goto out_drop_write;
ret = -EINVAL;
- if (!(capable(CAP_SYS_ADMIN) || (dst_file->f_mode & FMODE_WRITE)))
+ if (!allow_file_dedupe(dst_file))
goto out_drop_write;
ret = -EXDEV;
--
2.15.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
2018-09-10 23:21 [PATCH v6 0/2] vfs: fix dedupe permission check Mark Fasheh
2018-09-10 23:21 ` [PATCH 1/2] vfs: allow dedupe of user owned read-only files Mark Fasheh
@ 2018-09-10 23:21 ` Mark Fasheh
1 sibling, 0 replies; 3+ messages in thread
From: Mark Fasheh @ 2018-09-10 23:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Al Viro, linux-fsdevel, linux-api, Michael Kerrisk, linux-btrfs,
linux-xfs, Darrick J . Wong, Adam Borowski, David Sterba,
Mark Fasheh
Right now we return EINVAL if a process does not have permission to dedupe a
file. This was an oversight on my part. EPERM gives a true description of
the nature of our error, and EINVAL is already used for the case that the
filesystem does not support dedupe.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: David Sterba <dsterba@suse.com>
---
fs/read_write.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index be0e8723a049..c734bc2880a5 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1991,7 +1991,7 @@ int vfs_dedupe_file_range_one(struct file *src_file, loff_t src_pos,
if (ret < 0)
goto out_drop_write;
- ret = -EINVAL;
+ ret = -EPERM;
if (!allow_file_dedupe(dst_file))
goto out_drop_write;
--
2.15.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-09-10 23:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-10 23:21 [PATCH v6 0/2] vfs: fix dedupe permission check Mark Fasheh
2018-09-10 23:21 ` [PATCH 1/2] vfs: allow dedupe of user owned read-only files Mark Fasheh
2018-09-10 23:21 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).