GNU bug report logs - #75688
Replace wrapper scripts with search path value files in search-paths.d

Previous Next

Package: guix-patches;

Reported by: iyzsong <at> envs.net

Date: Mon, 20 Jan 2025 12:02:02 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 75688 <at> debbugs.gnu.org, 宋文武 <iyzsong <at> member.fsf.org>, Vivien Kraus <vivien <at> planete-kraus.eu>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: [bug#75688] [PATCH 0/2] Introduce GUIX_LIBRARY_PATH to replace harmful environment variables
Date: Wed, 22 Jan 2025 10:03:09 +0900
Hello,

宋文武 <iyzsong <at> envs.net> writes:

[...]

>> inheriting its parent environment, but otherwise I'm not sure I
>> understand the issue, especially how processing a .VARIABLE file instead
>> would handle this better?  Could yo give an example?
>
> A program try to load different versions of plugins via
> GIO_EXTRA_MODULES, QT_PLUGIN_PATHS could crash due to ABI incompatible, see:
>
> mix Qt 5.9.3 and 5.9.4: https://yhetil.org/guix/874jzl2n16.fsf <at> gmail.com/
> mix GIO modules with different glibc: https://yhetil.org/guix/87r0rvasph.fsf <at> jpoiret.xyz/
>
> In a desktop environment, with wrapper scripts you would get
> GIO_EXTRA_MODULES, GTK_PATH contains store paths:
>
> https://yhetil.org/guix/2c93c29e-032b-2b5e-6139-b28de456b47b <at> telenet.be/
>
> GIO_EXTRA_MODULES=/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/knm6b1dxg2j3vji4wrgngv99pvb6f5ff-glib-networking-2.70.0/lib/gio/modules::/run/current-system/profile/lib/gio/modules
> GTK_PATH=/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0:/gnu/store/fkl4fg06f538ryhiw4bs2iwwfs56g2k3-libcanberra-0.30/lib/gtk-3.0

I see; I agree that if the environment variables or not set by a search
path and instead picked up by the binary from some file, then it solves
this class of problem, but that seems equivalent to wrapping the
binaries, no?  You'd still have some glue code reading .VARIABLE and
then doing a bunch of setenv before launching the actual program, no?
That glue code is currently the shell or Guile script used to wrap the
binaries.

Unless we can fully eliminate search paths and propagation, we'll still
have the issue of having environment variables being set, even with the
use of .VARIABLE, as far s I understand.

> Then when you try to run a incompatible program (eg: with a newer glibc
> or gtk), those variables leaks from wrapper scripts will make the
> program crash.
>
> By replace those variables via .VARIABLE file, those starts with

nitpick: Perhaps it could be called .environment or
.environment-variables, similarly named as in our failed Guix builds.

[...]

As you can see, perhaps I'm still missing pieces of your big picture.  a
RFC/GCD documenting the idea, or a demo implementation if that's
easier/faster would help (code is often more succinct than text).

-- 
Thanks,
Maxim




This bug report was last modified 126 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.