diff options
| author | Maximilian Bosch <maximilian@mbosch.me> | 2025-05-16 15:06:37 +0200 |
|---|---|---|
| committer | Maximilian Bosch <maximilian@mbosch.me> | 2025-05-17 13:27:31 +0200 |
| commit | 2f4c74906d9e0d3c32a3a4e1db38f20a2c1501ad (patch) | |
| tree | c6711915f988f5eb7c75d7514384e72844cd8577 /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch | |
| parent | 2b01dbcf9184303691f0360899ea874eba8469d8 (diff) | |
glibc: use secure_getenv for loading locale archive
To quote `getenv(3)`:
> The GNU-specific secure_getenv() function is just like
> getenv() except that it returns NULL in cases where "secure
> execution" is required.
One of these cases is running in setuid mode. In this case, one could
make `sudo` load an arbitrary file as locale archive by modifying the
LOCALE_ARCHIVE env variable accordingly.
After consultation with the security team we came to the conclusion that
this is not exploitable by itself since it'd need another issue that
can be triggered by a maliciously crafted locale archive. Since this is
a valid issue nonetheless[1], I decided to fix it, but go through the
normal PR & staging lifecycle.
This patch also adds another fallback to
`/run/current-system/sw/lib/locale/locale-archive`: otherwise `sudo`
would fail to load any locale archive since that would be in
LOCALE_ARCHIVE/LOCALE_ARCHIVE_2_27 and thus setuid programs would
regress on translated output.
Thank you to Elliot Cameron for reporting this.
[1] glibc's internal environment filtering also prevents setuid
processes to use certain locale settings from the environment
such as LOCPATH.
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions
