If they mutated the real environment it could be even worse, since they're still privileged code and there are all sorts of environment variables that libraries read at runtime using `secure_getenv`.

I finally understand why they're trying to deprecate `pam_env`, despite its incredible utility. For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.

Ok yeah, I had actually misread what the vars were.

But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from.

To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.

> For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.

The only safe way to use pam_env's `user_readenv` parameter is as the final rule of `type=session`. This behaves as you'd expect, affecting the child process only.

It appears that openSUSE enables the option for other rule types (auth and/or account), in which case it affects the parent process as well. Oops!

For the record, user_readenv has been disabled since:

    commit 4c430f6f8391555bb1b7b78991afb20d35228efc
    Author: Tomas Mraz <tm@t8m.info>
    Date:   Mon Oct 11 14:24:30 2010 +0000
    
        Relevant BUGIDs:
        
        Purpose of commit: bugfix
        
        Commit summary:
        ---------------
        2010-10-11  Tomas Mraz  <t8m@centrum.cz>
        
                * modules/pam_env/pam_env.c: Change default for user_readenv to 0.
                * modules/pam_env/pam_env.8.xml: Document the new default for user_readenv.

... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.