passwdehd in libpam-mount 0.43 allows local users to overwrite arbitrary files via a symlink attack on a /tmp/passwdehd.##### temporary file. http://lists.debian.org/debian-devel/2008/08/msg00285.html
Created pam_mount tracking bugs for this issue CVE-2008-5138 Affects: F8 [bug #472110] CVE-2008-5138 Affects: F9 [bug #472111] CVE-2008-5138 Affects: Fdevel [bug #472112]
I need some guidance here. In the pam_mount version in F8 & F9 stable and devel, the script will not work, because the config file of pam_mount changed and the script was not ported to the new format. Also in newer upstream releases, the script is not shipped anymore. The only action the script would take on an up2date Fedora system would be to write, that the config file cannot be found. The question is now, how to proceed. The initial release of F8 (maybe F9, too) included an rpm where the script still worked somehow, but there was already another security update that included the config file change. The question is now, whether I should create a new update that does not include the affected script to make everyone aware that this vulnerability existed via the repository metadata and package update mailinglist, so that the administrators can decide, whether or not they want to upgrade. Fedora devel is imho not really affected, therefore I guess the bug can be closed.
The config file was renamed from /etc/security/pam_mount.conf to /etc/security/pam_mount.conf.xml with pam_mount 0.19, maybe you can forward this information to the debian people.
Till, is that likely that admins have some left-over pam_mount.conf file besides pam_mount.conf.xml? Even users that installed version that still used pam_mount.conf should have that file either removed during upgrade (if it was unchanged), or renamed to .rpmsave. Btw, why should Rawhide be less affected than F8/F9? All versions use 0.49, so all should be affected in pretty much the same way. As for updating now vs. later, given that this has quite low impact, further lowered by the fact that the problematic part of the script is unlikely to be reached on users' systems, it should be fine to postpone fixing this until there's another reason to do new spin of pam_mount packages (either bug or update to newer upstream version).
It is very unlikely that a pam_mount.conf file still exists on systems that have updated to pam_mount 0.49. But maybe some admins did not yet update their pam_mount package, because of the change to the XML file format or for some other reasons. Imho F10/devel is less affected, because there it is made sure that everyone is having pam_mount 0.49 and therefore there will be no pam_mount.conf file.