Re: [RESEND][PATCH v5 0/2] vfs: better dedupe permission check

On Tue, Aug 07, 2018 at 02:49:47PM -0700, Mark Fasheh wrote:

Hi Andrew,

Could I please have these patches upstreamed or at least 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 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.

[...]

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

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.

Note that the counterpart of these two patches for BTRFS_IOC_DEFRAG, which
fixes the same issues, is included in btrfs' for-next, slated for 4.19. 
While technically dedupe and defrag are independent, there would be somewhat
less confusion if both behave the same in the same kernel version.

Thus, it'd be nice if you would consider taking this.  Should be safe:
even the permission check is paranoid.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄⠀⠀⠀⠀ adjectives to use for the dish's name.