On Sat, Oct 21, 2017 at 12:40 PM, Nicolas Belouin <nicolas@xxxxxxxxxx> wrote: > > > On October 21, 2017 4:08:31 PM GMT+02:00, Nick Kralevich <nnk@xxxxxxxxxx> wrote: >>On Sat, Oct 21, 2017 at 6:28 AM, Nicolas Belouin <nicolas@xxxxxxxxxx> >>wrote: >>> In its current implementation the check is against CAP_SYS_ADMIN, >>> however this capability is bloated and inapropriate for this use. >>> Indeed the check aims to avoid dedupe against non writable files, >>> falling directly in the use case of CAP_DAC_OVERRIDE. >>> >>> Signed-off-by: Nicolas Belouin <nicolas@xxxxxxxxxx> >>> --- >>> 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 f0d4b16873e8..43cc7e84e29e 100644 >>> --- a/fs/read_write.c >>> +++ b/fs/read_write.c >>> @@ -1965,7 +1965,7 @@ int vfs_dedupe_file_range(struct file *file, >>struct file_dedupe_range *same) >>> u64 len; >>> int i; >>> int ret; >>> - bool is_admin = capable(CAP_SYS_ADMIN); >>> + bool is_admin = capable(CAP_SYS_ADMIN) || >>capable(CAP_DAC_OVERRIDE); >> >>Can you please reverse the order of the checks? In particular, on an >>SELinux based system, a capable() call generates an SELinux denial, >>and people often instinctively allow the first operation performed. >>Reordering the elements will ensure that the CAP_DAC_OVERRIDE denial >>(least permissive) is generated first. > > Will do in the v2 of every concerned patch. > That's still a bit wrong because of how audit works. What you really want is: bool have_either_global_cap(int cap1, int cap2); where, if neither cap is available, the audit message references cap1 and not cap2. Ditto for have_either_ns_cap(). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
