From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>, passt-dev@passt.top
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH v2 3/4] linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling
Date: Fri, 8 Nov 2024 13:53:29 +1100 [thread overview]
Message-ID: <20241108025330.3161314-4-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20241108025330.3161314-1-david@gibson.dropbear.id.au>
If CLOSE_RANGE_UNSHARE isn't defined, we define a fallback version of
close_range() which is a (successful) no-op. This is broken in several
ways:
* It doesn't actually fix compile if using old kernel headers, because
the caller of close_range() still directly uses CLOSE_RANGE_UNSHARE
unprotected by ifdefs
* Even if it did fix the compile, it means inconsistent behaviour between
a compile time failure to find the value (we silently don't close files)
and a runtime failure (we die with an error from close_range())
* Silently not closing the files we intend to close for security reasons
is probably not a good idea in any case
We don't want to simply error if close_range() or CLOSE_RANGE_UNSHARE isn't
available, because that would require running on kernel >= 5.9. On the
other hand there's not really any other way to flush all possible fds
leaked by the parent (close() in a loop takes over a minute). So in this
case print a warning and carry on.
As bonus this fixes a cppcheck error I see with some different options I'm
looking to apply in future.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
linux_dep.h | 12 ++++--------
util.c | 16 ++++++++++++++--
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/linux_dep.h b/linux_dep.h
index 3a41e42..240f50a 100644
--- a/linux_dep.h
+++ b/linux_dep.h
@@ -127,22 +127,18 @@ struct tcp_info_linux {
#include <linux/close_range.h>
-#ifdef CLOSE_RANGE_UNSHARE /* Linux kernel >= 5.9 */
/* glibc < 2.34 and musl as of 1.2.5 need these */
#ifndef SYS_close_range
#define SYS_close_range 436
#endif
+#ifndef CLOSE_RANGE_UNSHARE /* Linux kernel < 5.9 */
+#define CLOSE_RANGE_UNSHARE (1U << 1)
+#endif
+
__attribute__ ((weak))
/* cppcheck-suppress funcArgNamesDifferent */
int close_range(unsigned int first, unsigned int last, int flags) {
return syscall(SYS_close_range, first, last, flags);
}
-#else
-/* No reasonable fallback option */
-/* cppcheck-suppress funcArgNamesDifferent */
-int close_range(unsigned int first, unsigned int last, int flags) {
- return 0;
-}
-#endif
#endif /* LINUX_DEP_H */
diff --git a/util.c b/util.c
index 913f34b..126dedb 100644
--- a/util.c
+++ b/util.c
@@ -738,8 +738,20 @@ void close_open_files(int argc, char **argv)
rc = close_range(fd + 1, ~0U, CLOSE_RANGE_UNSHARE);
}
- if (rc)
- die_perror("Failed to close files leaked by parent");
+ if (rc) {
+ if (errno == ENOSYS || errno == EINVAL) {
+ /* This probably means close_range() or the
+ * CLOSE_RANGE_UNSHARE flag is not supported by the
+ * kernel. Not much we can do here except carry on and
+ * hope for the best.
+ */
+ warn(
+"Can't use close_range() to ensure no files leaked by parent");
+ } else {
+ die_perror("Failed to close files leaked by parent");
+ }
+ }
+
}
/**
--
2.47.0
next prev parent reply other threads:[~2024-11-08 2:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 2:53 [PATCH v2 0/4] Avoid running cppcheck on system headers David Gibson
2024-11-08 2:53 ` [PATCH v2 1/4] log: Only check for FALLOC_FL_COLLAPSE_RANGE availability at runtime David Gibson
2024-11-08 2:53 ` [PATCH v2 2/4] linux_dep: Move close_range() conditional handling to linux_dep.h David Gibson
2024-11-08 2:53 ` David Gibson [this message]
2024-11-08 2:53 ` [PATCH v2 4/4] cppcheck: Don't check the system headers David Gibson
2024-11-08 9:27 ` [PATCH v2 0/4] Avoid running cppcheck on " Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241108025330.3161314-4-david@gibson.dropbear.id.au \
--to=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
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 IMAP folder(s).