From 43c5af517c5662907d696273830e5336ff4f2a7b Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Wed, 1 May 2024 14:08:58 +0100 Subject: [PATCH] gdocumentportal: Treat more error codes as a permissions error If the file to be added is on a read-only filesystem, opening read/write will fail with EROFS. In this case we should fall back to opening it read-only, the same way we already do if write access is forbidden by DAC or MAC. An easy way to reproduce this test failure is to build and test GLib in a podman container, with its source code read-only and its build directory read/write: podman run --rm -it \ -v $(pwd):$(pwd):ro \ -v $(pwd)/_build:$(pwd)/_build:rw \ -w $(pwd) ... Before this commit, the dbus-appinfo test would fail, because opening ${srcdir}/gio/tests/org.gtk.test.dbusappinfo.flatpak.desktop read/write would fail with EROFS. For completeness, give similar handling to the other error codes documented in Linux open(2) that might succeed if re-attempted using read-only access: according to that documentation, we could get EPERM if opening read/write is prevented by fcntl F_ADD_SEALS, or ETXTBSY if the file is an executable that is currently being run. Signed-off-by: Simon McVittie --- gio/gdocumentportal.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/gio/gdocumentportal.c b/gio/gdocumentportal.c index 531156660..0b55c3ef9 100644 --- a/gio/gdocumentportal.c +++ b/gio/gdocumentportal.c @@ -101,6 +101,15 @@ opening_ro_might_succeed (int saved_errno) { case EACCES: case EISDIR: +#ifdef EPERM + case EPERM: +#endif +#ifdef EROFS + case EROFS: +#endif +#ifdef ETXTBSY + case ETXTBSY: +#endif return TRUE; default: