public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
* [rpms/7zip] epel9: Load 7z.so from a fixed libexec path instead of deriving it from argv[0]
@ 2026-07-01 17:10 Michel Lind
  0 siblings, 0 replies; only message in thread
From: Michel Lind @ 2026-07-01 17:10 UTC (permalink / raw)
  To: git-commits

            A new commit has been pushed.

            Repo   : rpms/7zip
            Branch : epel9
            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=epel9

            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 17:10 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-01 17:10 [rpms/7zip] epel9: 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