Python for PAM is fine for exploring, but it's a bad idea for "serious" modules.
That's because your PAM module might be called within the context of another Python interpreter. That might not be in a state that can run your code.
Even libc++ for C++ can cause issues.
Ideally, PAM should just die and be replaced by a simple network service on the DBUS. PolKit is actually pretty decent, although its choice of the language sucks.
Existing PAM modules implement certain login session setup procedures which have to be performed from within the calling process. (Writing to /proc/self/loginuid, for example.) That part is going to be difficult to replace because I don't think we have the required kernel interfaces today that would permit performing this step from the outside (perhaps using a file descriptor obtained via SO_PEERPIDFD?).
This part of the login process _really_ irks me. It's just badly designed, and it's a magnet for all kinds of security vulnerabilities.
One way to fix it, is to standardize on a "shim" process. So the session manager can prepare all the required information within the root context: env vars, Kerberos/OIDC tokens, PGP key socket paths, and so on. Locally configured modules can augment that with their own data.
Then it should package this information into a self-contained packet via memfd, and launch a shim process within the target user's context. The shim can then do whatever it needs, and finally exec the login shell.
So at no point, the privileged context should poke the less-privileged context directly. The privilege transition should happen only once, and it can be done within a clean fully controlled environment.
That's because your PAM module might be called within the context of another Python interpreter. That might not be in a state that can run your code.
Even libc++ for C++ can cause issues.
Ideally, PAM should just die and be replaced by a simple network service on the DBUS. PolKit is actually pretty decent, although its choice of the language sucks.