From patchwork Tue Jul 17 20:14:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Fasheh X-Patchwork-Id: 10530531 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F384D600D0 for ; Tue, 17 Jul 2018 20:14:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E0F052848F for ; Tue, 17 Jul 2018 20:14:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D4DFA285BE; Tue, 17 Jul 2018 20:14:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5D95E2848F for ; Tue, 17 Jul 2018 20:14:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730933AbeGQUsg (ORCPT ); Tue, 17 Jul 2018 16:48:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:47856 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729840AbeGQUsg (ORCPT ); Tue, 17 Jul 2018 16:48:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 02E03ACA8; Tue, 17 Jul 2018 20:14:17 +0000 (UTC) Date: Tue, 17 Jul 2018 20:14:17 +0000 From: Mark Fasheh To: "Darrick J. Wong" Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org, Adam Borowski , David Sterba , Michael Kerrisk , linux-api@vger.kernel.org Subject: Re: [RESEND][PATCH v4 0/2] vfs: better dedupe permission check Message-ID: <20180717201417.GE10690@wotan.suse.de> Reply-To: Mark Fasheh References: <20180717190906.31073-1-mfasheh@suse.de> <20180717194818.GV32415@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180717194818.GV32415@magnolia> Organization: SUSE Labs User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP CCing Michael Kerrisk and linux-api The patch at the end of this e-mail updates our man page for ioctl_fideduperange to reflect the changes proposed in this patch series: https://marc.info/?l=linux-fsdevel&m=153185457324037&w=2 Any feedback would be appreciated. Thanks in advance. --Mark On Tue, Jul 17, 2018 at 12:48:18PM -0700, Darrick J. Wong wrote: > On Tue, Jul 17, 2018 at 12:09:04PM -0700, Mark Fasheh wrote: > > Hi Al, > > > > The following patches fix a couple of issues with the permission check > > we do in vfs_dedupe_file_range(). I sent them out for a few times now, > > a changelog is attached. If they look ok to you, I'd appreciate them > > being pushed upstream. > > > > You can get them from git if you like: > > > > git pull https://github.com/markfasheh/linux dedupe-perms > > > > I also have a set of patches against 4.17 if you prefer. The code and > > testing are identical: > > > > git pull https://github.com/markfasheh/linux dedupe-perms-v4.17 > > > > > > 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). > > > > Please apply. > > > > Thanks, > > --Mark > > > > 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 > > > > [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 > > --- > > man2/ioctl_fideduperange.2 | 8 +++++--- > > Mmm, man page update, thank you for editing the documentation too! > > Please cc linux-api and Michael Kerrisk so this can go upstream. From: Mark Fasheh [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 --- 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.