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

Previous Next

Full log

View this message in rfc822 format

From: 宋文武 <iyzsong <at> envs.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
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: Tue, 21 Jan 2025 22:39:34 +0800

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

>> Okay, I changed the plan, since use only one env like GUIX_LIBRARY_PATH
>> would lead to some form of 'stats storm', and the logic is not harder
>> for patching different variables. If we get rid of wrapper scripts, the
>> "noise" will only contains profile paths, so are acceptable..
>>
>> Now I get this patch for glib:
>>
>> 1. add a `gchar **g_build_guix_search_path_dirs (const gchar *variable)`
>>    function to GLIB, which handle .VARIABLE file in addition to the env
>>    value.  Those .VARIABLE files sit at the same directory of
>>    executable, would be used to replace wrapper script.  As said early,
>>    wrapper scripts leaks environment variables could cause incompatable
>>    problems.
>>
>> 2. Use `g_build_guix_search_path_dirs` for GUIX_GIO_EXTRA_MODULES,
>>    GUIX_GSETTINGS_SCHEMA_DIR, and etc. (later).
>>
>> 3. (later) Modify wrap-program usages to use .VARIABLE files to get rid
>>    of environment variables leaks.
>
> This reminds me of how Python virtualenv works, IIRC.  What do you mean
> by "wrapper scripts leak environment variables and could cause
> incompatibility problems" ?  Sure, if your term binary is wrapped, your
> shell will have these environment variables as its a child process
> 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

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
'/gnu/store/' won't get exported to the shell and desktop sessions,
since they're not in the environ, but read from file (any executable
will read its unique set of .VARIABLE files) and used by executables
directly.  So it should reduce the chance of incompatible, also if we
wrap programs need dconf/glib-networking with .VARIABLE file, there will
be no need to install dconf/glib-networking in the system profile,
reduce the risk more.

'/run/current-system/' still could cause problems though, which user can
update all packages sync or choose to not mix profiles.

Previous Next

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