Eric McCorkle wrote in <b265fa82-53f2-59f4-65c2-b07a9412b...@metricspace.net>: |Interesting, I wasn't aware of the upstream module. I'd say that's
It's existence was the reason i have readded (now optional, and a tad different) session support for my pam_xdg PAM module, because i was thinking that, if such a many-eyes-seen thing of a software project that claims to be and aims at being enterprise, ships such a terrible and terribly broken thing, then i can also offer session tracking. But my manual at least states CAVEATS On Unix systems any “daemonized” program or script is reparented to the program running with PID 1, most likely leaving the PAM user session without PAM recognizing this. Yet careless such code may hold or expect availability of resources of the session it just left, truly performing cleanup when sessions end seems thus unwise. Since so many PAM modules do support session tracking and cleanup pam_xdg.so readded optional sup‐ port for this. But the real solution would be PAM session tracking in-kernel, somehow, wouldn't it? Also, on FreeBSD and OpenPAM many separate files exist in /etc/pam.d for things which might open a session, whereas linuxpam at least has /etc/pam.d/common-session; it has many common- things in fact, and in /etc/pam.d/sshd i for example see # # /etc/pam.d/sshd - openssh service module configuration # auth include common-auth account include common-account password include common-password session include common-session --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)