Re: bug#76428: [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@envs.net> skribis:
>
>>   ld.so.cache
>>   search-paths.d
>>     GUIX_XDG_DATA_DIRS
>>     GUIX_GIO_EXTRA_MODULES
>>     GUIX_GTK4_PATH
>
> I don’t think the “GUIX_” prefix is really justified in the proposal.

Sure.  There are 2 reasons, one is to avoid broke foreign systems (
GUIX_GIO_EXTRA_MODULES, GUIX_GTK4_PATH), another is about priority
(GUIX_XDG_*) I'll explain later.

>
> There’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow
> that this can be generalized to every search path environment variable.
>
> For example, the XDG_ variables are honored by a lot of software, not
> just GLib- or Qt-based software, and it’s unrealistic to patch them all.
> It’s also undesirable: generally speaking, we want to stay as close to
> upstream as possible so that documentation, tutorials, and scripts found
> elsewhere also work on Guix.

Yes, we introduced GUIX_PYTHONPATH, GUIX_GTK* to avoid ABI
incompatibility problems between different programs from foreign systems
and Guix systems.  But XDG_DATA_DIRS, as it's designed for shareable
data files, won't have ABI incompatibility problems, and we rely on it
for a foreign desktop launch to find applications (via desktop files),
fonts installed from Guix.

So do we need 'GUIX_XDG_*'?  Well, In 'wrap-program' we can specifiy how
the wrapped environment variables are going to be combined with the
system level variables in 3 positions: prefix, suffix or = (exact).  The
priority between wrapped and system level variables influence the
robustness of programs.

For plugins which might have ABI problems, we'll use 'prefix', so a
wrapped program always load the correct ones (eg: qtbase) first, and
hopefully they can ignore the possible incompatible ones (eg: a qt
theme plugin) with reduced functions but still works.

Or for not real search paths which only support a single directory or
file, we'll use '=' (eg: SSL_CERT_FILE).

But for XDG_DATA_DIRS and XDG_CONFIG_DIRS, we'll want to use 'suffix',
so that the shared combined data (icons, mime databases) will be used
instead of a seperated incomplete ones.  Also it allow user to customize
them as usually, or 'guix home' or 'guix system' to custom them at
profile level.

In the specified search-paths.d implementation, for simplify reason, the
envs from search-paths.d files are always used in 'prefix' way.  For '='
cases, we could patch it to a real search path (eg:
GUIX_GDK_PIXBUF_MODULE_FILES), or hardcode it (eg:
QTWEBENGINEPROCESS_PATH #75966).  For 'suffix' cases, it uses 2
variables, that's prefer XDG_DATA_DIRS (set by profile or foreign
system) over GUIX_XDG_DATA_DIRS (set by search-paths.d, not leaking).

>
>> ## Find the location of the current executable
>>
>> To find its search path configuration files when an executable is running,
>> we can first find the location of the executable.  Conveniently, Linux
>> provides a pseudo-file `/proc/self/exe` for this exact purpose, which works
>> well for ELF executables.   But for an interpreter script, `/proc/self/exe`
>> would return the file name of its interpreter instead of the script, so
>> we patch interpreters to set 2 environment variables:
>>
>>   - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter
>>   - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script
>
> We won’t patch every interpreter out there, that’s not reasonable.

Yes, python should be the most, also we can avoid patching and still use
'wrap-program' for them.

>
> These two variables could also have unexpected consequences since an
> attacker could override them to cause confusion.

The check (current /prof/self-exe == GUIX_INTERPRETER_FILE) done in the
client side should prevent the attack or confusion, if the interpreter
haven't changed then there should be no way to modify
GUIX_MAIN_SCRIPT_FILE set by the interpreter.


> [...]
>
> I’m concerned about the cost of maintaining these patches.  Again, the
> ld.so patch (for glibc) sets a precedent, but this part of glibc changes
> relatively rarely, and it’s just one patch; what if we have to maintain
> ten such patches in big and changing libraries like GLib and Qt?

I'm totally fine with reject the implementation due to maintaince
burden.  I could polish the patches later for easier review and decide
they are reasonable or not.

>
> Overall, I think I’d be reassured if we reduced the scope a little bit:
> don’t insist on the “GUIX_” prefix, focus on GTK and Qt applications.

Okay, I'll send GUIX_GIO_EXTRA_MODULES as a seperated patch later.  For
'GUIX_XDG_DATA_DIRS' and 'GUIX_XDG_CONFIG_DIRS', do you think the
current implementation plan (GUIX_ ones only used by search-paths.d,
only XDG_DATA_* still set by profile and visible, use 2 variables due to
simplify reason) fine?

Thank you!