public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
* [rpms/7zip] rawhide: Load 7z.so from a fixed libexec path instead of deriving it from argv[0]
@ 2026-07-01 15:49 Michel Lind
0 siblings, 0 replies; only message in thread
From: Michel Lind @ 2026-07-01 15:49 UTC (permalink / raw)
To: git-commits
A new commit has been pushed.
Repo : rpms/7zip
Branch : rawhide
Commit : c998a880bb77e43259aeea79c44d93fbbd5c51e2
Author : Michel Lind <salimma@fedoraproject.org>
Date : 2026-07-01T16:37:12+01:00
Stats : +12/-6 in 1 file(s)
URL : https://src.fedoraproject.org/rpms/7zip/c/c998a880bb77e43259aeea79c44d93fbbd5c51e2?branch=rawhide
Log:
Load 7z.so from a fixed libexec path instead of deriving it from argv[0]
- Resolves: rhbz#2491337
The 7z frontend located its codec plugin (7z.so) relative to a directory
derived from argv[0], and the Fedora patch only rewrote that to
%{_libexecdir}/7zip for empty, /usr/bin/ and /bin/ invocation paths.
On merged-usr systems /usr/sbin -> bin and /sbin -> usr/sbin, so
/usr/sbin/7z and /sbin/7z are the same binary as /usr/bin/7z. root's
default PATH (ENV_SUPATH) includes the sbin directories, so root can
invoke 7z through a /usr/sbin or /sbin path; the prefix check then missed,
the plugin directory stayed /usr/sbin (which has no 7z.so), and every
plugin-backed format failed with "Cannot open the file as archive".
Whitelisting bin directories is whack-a-mole — any symlink can point
elsewhere. Since the packaged 7z always loads its plugin from a fixed
location, stop deriving the directory from argv[0] and hardcode
%{_libexecdir}/7zip unconditionally.
Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Michel Lind <salimma@fedoraproject.org>
---
diff --git a/7zip-find-so-in-libexec.diff b/7zip-find-so-in-libexec.diff
index a569f97..f5c0e94 100644
--- a/7zip-find-so-in-libexec.diff
+++ b/7zip-find-so-in-libexec.diff
@@ -1,15 +1,21 @@
+diff --git a/CPP/7zip/UI/Common/ArchiveCommandLine.cpp b/CPP/7zip/UI/Common/ArchiveCommandLine.cpp
+index 7fe18fb..4b79e2d 100644
--- a/CPP/7zip/UI/Common/ArchiveCommandLine.cpp
+++ b/CPP/7zip/UI/Common/ArchiveCommandLine.cpp
-@@ -1894,8 +1894,10 @@ FString GetModuleDirPrefix()
+@@ -1894,8 +1894,14 @@ FString GetModuleDirPrefix()
FString s;
-
+
s = fas2fs(g_ModuleDirPrefix);
- if (s.IsEmpty())
- s = FTEXT(".") FSTRING_PATH_SEPARATOR;
-+ if (s.IsEmpty() ||
-+ s.IsPrefixedBy("__Z7_PREFIX__/bin/") ||
-+ s.IsPrefixedBy("/bin/"))
-+ s = FTEXT("__Z7_PREFIX__/libexec/7zip") FSTRING_PATH_SEPARATOR;
++ // Fedora: 7z.so is always installed in __Z7_PREFIX__/libexec/7zip,
++ // regardless of how the frontend binary was invoked. Deriving the plugin
++ // directory from argv[0] is fragile: it breaks whenever 7z is reached via
++ // /sbin or /usr/sbin (both in root's default PATH, and symlinks to /usr/bin
++ // on merged-usr systems) or via any other symlink, failing with
++ // "Cannot open the file as archive". So ignore argv[0] and hardcode the
++ // install location. rhbz#2491337
++ s = FTEXT("__Z7_PREFIX__/libexec/7zip") FSTRING_PATH_SEPARATOR;
return s;
/*
setenv("_7ZIP_HOME_DIR", "/test/", 0);
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2026-07-01 15:49 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-01 15:49 [rpms/7zip] rawhide: Load 7z.so from a fixed libexec path instead of deriving it from argv[0] Michel Lind
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox