summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
diff options
context:
space:
mode:
authorMaximilian Bosch <maximilian@mbosch.me>2025-05-16 15:06:37 +0200
committerMaximilian Bosch <maximilian@mbosch.me>2025-05-17 13:27:31 +0200
commit2f4c74906d9e0d3c32a3a4e1db38f20a2c1501ad (patch)
treec6711915f988f5eb7c75d7514384e72844cd8577 /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
parent2b01dbcf9184303691f0360899ea874eba8469d8 (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