linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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; 13+ 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	[flat|nested] 13+ 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; 13+ 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	[flat|nested] 13+ 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; 13+ 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	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-17  5:15         ` Zygo Blaxell
@ 2018-05-17 23:03           ` Mark Fasheh
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Fasheh @ 2018-05-17 23:03 UTC (permalink / raw)
  To: Zygo Blaxell; +Cc: Darrick J. Wong, linux-fsdevel, linux-btrfs, linux-xfs

On Thu, May 17, 2018 at 01:15:51AM -0400, Zygo Blaxell wrote:
> On Sun, May 13, 2018 at 11:26:39AM -0700, Darrick J. Wong wrote:
> > On Sun, May 13, 2018 at 06:21:52PM +0000, Mark Fasheh wrote:
> > > On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> > > > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > > > > 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>
> > > > > ---
> > > > >  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 77986a2e2a3b..8edef43a182c 100644
> > > > > --- a/fs/read_write.c
> > > > > +++ b/fs/read_write.c
> > > > > @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
> > > > >  			info->status = -EINVAL;
> > > > >  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
> > > > >  			     uid_eq(current_fsuid(), dst->i_uid))) {
> > > > > -			info->status = -EINVAL;
> > > > > +			info->status = -EPERM;
> > > > 
> > > > Hmm, are we allowed to change this aspect of the kabi after the fact?
> > > > 
> > > > Granted, we're only trading one error code for another, but will the
> > > > existing users of this care?  xfs_io won't and I assume duperemove won't
> > > > either, but what about bees? :)
> > > 
> > > Yeah if you see my initial e-mail I check bees and also rust-btrfs. I think
> > > this is fine as we're simply expanding on an error code return. There's no
> > > magic behavior expected with respect to these error codes either.
> > 
> > Ok.  No objections from me, then.
> > 
> > Acked-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> For what it's worth, no objection from me either.  ;)
> 
> bees runs only with admin privilege and will never hit the modified line.

Awesome, thanks for the review Zygo.
	--Mark

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-13 18:26       ` Darrick J. Wong
@ 2018-05-17  5:15         ` Zygo Blaxell
  2018-05-17 23:03           ` Mark Fasheh
  0 siblings, 1 reply; 13+ messages in thread
From: Zygo Blaxell @ 2018-05-17  5:15 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: Mark Fasheh, linux-fsdevel, linux-btrfs, linux-xfs

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

On Sun, May 13, 2018 at 11:26:39AM -0700, Darrick J. Wong wrote:
> On Sun, May 13, 2018 at 06:21:52PM +0000, Mark Fasheh wrote:
> > On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> > > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > > > 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>
> > > > ---
> > > >  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 77986a2e2a3b..8edef43a182c 100644
> > > > --- a/fs/read_write.c
> > > > +++ b/fs/read_write.c
> > > > @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
> > > >  			info->status = -EINVAL;
> > > >  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
> > > >  			     uid_eq(current_fsuid(), dst->i_uid))) {
> > > > -			info->status = -EINVAL;
> > > > +			info->status = -EPERM;
> > > 
> > > Hmm, are we allowed to change this aspect of the kabi after the fact?
> > > 
> > > Granted, we're only trading one error code for another, but will the
> > > existing users of this care?  xfs_io won't and I assume duperemove won't
> > > either, but what about bees? :)
> > 
> > Yeah if you see my initial e-mail I check bees and also rust-btrfs. I think
> > this is fine as we're simply expanding on an error code return. There's no
> > magic behavior expected with respect to these error codes either.
> 
> Ok.  No objections from me, then.
> 
> Acked-by: Darrick J. Wong <darrick.wong@oracle.com>

For what it's worth, no objection from me either.  ;)

bees runs only with admin privilege and will never hit the modified line.

If bees is started without admin privilege, the TREE_SEARCH_V2 ioctl
fails.  bees uses this ioctl to walk over all the data in the filesystem,
so without admin privilege, bees never opens, reads, or dedupes anything.

bees relies on having an accurate internal model of btrfs structure and
behavior to issue dedup commands that will work and do useful things;
however, unexpected kernel behavior or concurrent user data changes
will make some dedups fail.  When that happens bees just abandons the
extent immediately:  a user data change will be handled in the next pass
over the filesystem, but an unexpected kernel behavior needs bees code
changes to correctly predict the new kernel behavior before the dedup
can be reattempted.

> --D
> 
> > 	--Mark
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-11 19:26 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
  2018-05-12  0:06   ` Darrick J. Wong
@ 2018-05-14 14:58   ` David Sterba
  1 sibling, 0 replies; 13+ messages in thread
From: David Sterba @ 2018-05-14 14:58 UTC (permalink / raw)
  To: Mark Fasheh; +Cc: linux-fsdevel, linux-btrfs, linux-xfs

On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> 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>

Acked-by: David Sterba <dsterba@suse.com>

We've been using EINVAL when the request is invalid in the ioctls, eg.
combination of arguments that does not make sense, while EPERM is for
cases when the request is ok but there's still some permission missing,

>  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
>  			     uid_eq(current_fsuid(), dst->i_uid))) {
> -			info->status = -EINVAL;
> +			info->status = -EPERM;

exactly like this.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-13 18:21     ` Mark Fasheh
@ 2018-05-13 18:26       ` Darrick J. Wong
  2018-05-17  5:15         ` Zygo Blaxell
  0 siblings, 1 reply; 13+ messages in thread
From: Darrick J. Wong @ 2018-05-13 18:26 UTC (permalink / raw)
  To: Mark Fasheh; +Cc: linux-fsdevel, linux-btrfs, linux-xfs

On Sun, May 13, 2018 at 06:21:52PM +0000, Mark Fasheh wrote:
> On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > > 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>
> > > ---
> > >  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 77986a2e2a3b..8edef43a182c 100644
> > > --- a/fs/read_write.c
> > > +++ b/fs/read_write.c
> > > @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
> > >  			info->status = -EINVAL;
> > >  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
> > >  			     uid_eq(current_fsuid(), dst->i_uid))) {
> > > -			info->status = -EINVAL;
> > > +			info->status = -EPERM;
> > 
> > Hmm, are we allowed to change this aspect of the kabi after the fact?
> > 
> > Granted, we're only trading one error code for another, but will the
> > existing users of this care?  xfs_io won't and I assume duperemove won't
> > either, but what about bees? :)
> 
> Yeah if you see my initial e-mail I check bees and also rust-btrfs. I think
> this is fine as we're simply expanding on an error code return. There's no
> magic behavior expected with respect to these error codes either.

Ok.  No objections from me, then.

Acked-by: Darrick J. Wong <darrick.wong@oracle.com>

--D

> 	--Mark
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-12  0:06   ` Darrick J. Wong
                       ` (2 preceding siblings ...)
  2018-05-13 14:30     ` Adam Borowski
@ 2018-05-13 18:21     ` Mark Fasheh
  2018-05-13 18:26       ` Darrick J. Wong
  3 siblings, 1 reply; 13+ messages in thread
From: Mark Fasheh @ 2018-05-13 18:21 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: linux-fsdevel, linux-btrfs, linux-xfs

On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > 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>
> > ---
> >  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 77986a2e2a3b..8edef43a182c 100644
> > --- a/fs/read_write.c
> > +++ b/fs/read_write.c
> > @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
> >  			info->status = -EINVAL;
> >  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
> >  			     uid_eq(current_fsuid(), dst->i_uid))) {
> > -			info->status = -EINVAL;
> > +			info->status = -EPERM;
> 
> Hmm, are we allowed to change this aspect of the kabi after the fact?
> 
> Granted, we're only trading one error code for another, but will the
> existing users of this care?  xfs_io won't and I assume duperemove won't
> either, but what about bees? :)

Yeah if you see my initial e-mail I check bees and also rust-btrfs. I think
this is fine as we're simply expanding on an error code return. There's no
magic behavior expected with respect to these error codes either.
	--Mark

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-12  0:06   ` Darrick J. Wong
  2018-05-12  4:15     ` Amir Goldstein
  2018-05-12  4:37     ` Duncan
@ 2018-05-13 14:30     ` Adam Borowski
  2018-05-13 18:21     ` Mark Fasheh
  3 siblings, 0 replies; 13+ messages in thread
From: Adam Borowski @ 2018-05-13 14:30 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: Mark Fasheh, linux-fsdevel, linux-btrfs, linux-xfs

On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > 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.

> > -			info->status = -EINVAL;
> > +			info->status = -EPERM;
> 
> Hmm, are we allowed to change this aspect of the kabi after the fact?
> 
> Granted, we're only trading one error code for another, but will the
> existing users of this care?  xfs_io won't and I assume duperemove won't
> either, but what about bees? :)

There's more:
https://codesearch.debian.net/search?q=FILE_EXTENT_SAME

This includes only software that has been packaged for Debian (notably, not
bees), but that gives enough interesting coverage.  And none of these cases
discriminate between error codes -- they merely report them to the user.

Thus, I can't think of a downside of making the error code more accurate.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!
⠈⠳⣄⠀⠀⠀⠀ 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-12  0:06   ` Darrick J. Wong
  2018-05-12  4:15     ` Amir Goldstein
@ 2018-05-12  4:37     ` Duncan
  2018-05-13 14:30     ` Adam Borowski
  2018-05-13 18:21     ` Mark Fasheh
  3 siblings, 0 replies; 13+ messages in thread
From: Duncan @ 2018-05-12  4:37 UTC (permalink / raw)
  To: linux-btrfs; +Cc: linux-fsdevel

Darrick J. Wong posted on Fri, 11 May 2018 17:06:34 -0700 as excerpted:

> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
>> 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>
>> ---
>>  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 77986a2e2a3b..8edef43a182c 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
>>  			info->status = -EINVAL;
>>  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
>>  			     uid_eq(current_fsuid(), dst->i_uid))) {
>> -			info->status = -EINVAL;
>> +			info->status = -EPERM;
> 
> Hmm, are we allowed to change this aspect of the kabi after the fact?
> 
> Granted, we're only trading one error code for another, but will the
> existing users of this care?  xfs_io won't and I assume duperemove won't
> either, but what about bees? :)

>From the 0/2 cover-letter:

>>> 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).

> --D
> 
>>  		} else if (file->f_path.mnt != dst_file->f_path.mnt) {
>>  			info->status = -EXDEV;
>>  		} else if (S_ISDIR(dst->i_mode)) {
>> -- 
>> 2.15.1
>>

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-12  0:06   ` Darrick J. Wong
@ 2018-05-12  4:15     ` Amir Goldstein
  2018-05-12  4:37     ` Duncan
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Amir Goldstein @ 2018-05-12  4:15 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: Mark Fasheh, linux-fsdevel, Linux Btrfs, linux-xfs

On Sat, May 12, 2018 at 3:06 AM, Darrick J. Wong
<darrick.wong@oracle.com> wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
>> 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>
>> ---
>>  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 77986a2e2a3b..8edef43a182c 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
>>                       info->status = -EINVAL;
>>               } else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
>>                            uid_eq(current_fsuid(), dst->i_uid))) {
>> -                     info->status = -EINVAL;
>> +                     info->status = -EPERM;
>
> Hmm, are we allowed to change this aspect of the kabi after the fact?
>
> Granted, we're only trading one error code for another, but will the
> existing users of this care?  xfs_io won't and I assume duperemove won't
> either, but what about bees? :)
>

Relaxing -EINVAL is the common case with kabi.
Every new flag we add support for does that and is it also common
that a new flag we support is restricted for certain capabilities so
EINVAL is replaced with EPERM.
BTW, man page doesn't say anything about the is_admin case.

IMO EPERM makes perfect sense here and btw, we also return
EPERM from overlayfs if dst is on lower layer.

Mark,

Please be aware that these changes conflict with Miklos' dedupe-cleanup
patches, so I suggest you collaborate on that
https://marc.info/?l=linux-fsdevel&m=152568128031031&w=2

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-11 19:26 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
@ 2018-05-12  0:06   ` Darrick J. Wong
  2018-05-12  4:15     ` Amir Goldstein
                       ` (3 more replies)
  2018-05-14 14:58   ` David Sterba
  1 sibling, 4 replies; 13+ messages in thread
From: Darrick J. Wong @ 2018-05-12  0:06 UTC (permalink / raw)
  To: Mark Fasheh; +Cc: linux-fsdevel, linux-btrfs, linux-xfs

On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> 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>
> ---
>  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 77986a2e2a3b..8edef43a182c 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
>  			info->status = -EINVAL;
>  		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
>  			     uid_eq(current_fsuid(), dst->i_uid))) {
> -			info->status = -EINVAL;
> +			info->status = -EPERM;

Hmm, are we allowed to change this aspect of the kabi after the fact?

Granted, we're only trading one error code for another, but will the
existing users of this care?  xfs_io won't and I assume duperemove won't
either, but what about bees? :)

--D

>  		} else if (file->f_path.mnt != dst_file->f_path.mnt) {
>  			info->status = -EXDEV;
>  		} else if (S_ISDIR(dst->i_mode)) {
> -- 
> 2.15.1
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted
  2018-05-11 19:26 [PATCH 0/2] vfs: better dedupe permission check Mark Fasheh
@ 2018-05-11 19:26 ` Mark Fasheh
  2018-05-12  0:06   ` Darrick J. Wong
  2018-05-14 14:58   ` David Sterba
  0 siblings, 2 replies; 13+ messages in thread
From: Mark Fasheh @ 2018-05-11 19:26 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: linux-btrfs, linux-xfs, 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>
---
 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 77986a2e2a3b..8edef43a182c 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -2038,7 +2038,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
 			info->status = -EINVAL;
 		} else if (!(is_admin || (dst_file->f_mode & FMODE_WRITE) ||
 			     uid_eq(current_fsuid(), dst->i_uid))) {
-			info->status = -EINVAL;
+			info->status = -EPERM;
 		} else if (file->f_path.mnt != dst_file->f_path.mnt) {
 			info->status = -EXDEV;
 		} else if (S_ISDIR(dst->i_mode)) {
-- 
2.15.1

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-09-11  4:17 UTC | newest]

Thread overview: 13+ 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
  -- strict thread matches above, loose matches on Subject: below --
2018-05-11 19:26 [PATCH 0/2] vfs: better dedupe permission check Mark Fasheh
2018-05-11 19:26 ` [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted Mark Fasheh
2018-05-12  0:06   ` Darrick J. Wong
2018-05-12  4:15     ` Amir Goldstein
2018-05-12  4:37     ` Duncan
2018-05-13 14:30     ` Adam Borowski
2018-05-13 18:21     ` Mark Fasheh
2018-05-13 18:26       ` Darrick J. Wong
2018-05-17  5:15         ` Zygo Blaxell
2018-05-17 23:03           ` Mark Fasheh
2018-05-14 14:58   ` David Sterba

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).