For the record, the patch (0010-set-language.patch) is not present in the accountsservice package in Debian, neither in unstable, (0.6.55-3) testing (0.6.55-3),

For the record, the patch (0010-set-language.patch) is not present in the accountsservice package in Debian, neither in unstable, (0.6.55-3) testing (0.6.55-3), nor stable (0.6.54.2). https://sources.debian.org/src/accountsservice/0.6.55-3/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.55-3/debi... https://sources.debian.org/src/accountsservice/0.6.45-2/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.45-2/debi... The changes that fix both vulnerabilities can be viewed here: https://git.launchpad.net/ubuntu/+source/accountsservice/commit/debian/patches/0010-set-language.patch?h=ubuntu/focal-updates&id=7bfa70006b90b76ccb43bfed30463594857591ae https://git.launchpad.net/ubuntu/+source/accountsservice/com... Personally I question the logic of having accounts-daemon grovel through pam_env's config files in the first place. This isn't an API, it's an implementation detail! It just seems like a bad idea, even ignoring the vulnerability which anyone who isn't an absolute expert on the semantics of real/effective/saved UIDs & how to safely change them could have made. https://www.usenix.org/conference/11th-usenix-security-symposium/setuid-demystified https://www.usenix.org/conference/11th-usenix-security-sympo... (the famous Sendmail vulnerability therein is actually the _opposite_ of the accountsservice problem... sendmail _should_ have set the real uid as well as the effective uid, so that its effective uid could never be changed back to 0). LWN has an excellent series of articles about thedesign of UNIX, one of which explains the problems with setuid: https://lwn.net/Articles/416494/ https://lwn.net/Articles/416494/