From 2e66e1732fced7af20fa76c60e636d39a1767d48 Mon Sep 17 00:00:00 2001 From: =?utf8?q?P=C3=A1draig=20Brady?= Date: Sat, 8 May 2021 19:23:20 +0100 Subject: [PATCH] copy: handle system security config issues with copy_file_range() * src/copy.c (sparse_copy): Upon EPERM from copy_file_range(), fall back to a standard copy, which will give a more accurate error as to whether the issue is with the source or destination. Also this will avoid the issue where seccomp or apparmor are not configured to handle copy_file_range(), in which case the fall back standard copy would succeed without issue. This specific issue with seccomp was noticed for example in: https://github.com/golang/go/issues/40900 --- src/copy.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/copy.c b/src/copy.c index f626cfed72..e929963901 100644 --- a/src/copy.c +++ b/src/copy.c @@ -294,6 +294,15 @@ sparse_copy (int src_fd, int dest_fd, char *buf, size_t buf_size, || errno == EINVAL || errno == EBADF || errno == EXDEV || errno == ETXTBSY) break; + + /* copy_file_range might not be enabled in seccomp filters, + so retry with a standard copy. EPERM can also occur + for immutable files, but that would only be in the edge case + where the file is made immutable after creating/truncating, + in which case the (more accurate) error is still shown. */ + if (errno == EPERM && *total_n_read == 0) + break; + if (errno == EINTR) n_copied = 0; else -- 2.47.2