--- Begin Message ---
Package: libpam0g
Version: 0.72-35
Severity: normal
Tags: security
Hi,
Apparently, changes to pam won't affect cron unless it is restarted. I know
this because I have several boxes on which I installed the broken libpam0g
0.75, and the problems only started after a reboot. One of them has been
running for 113 days now, and the pam bugs don't manifest themselves.
When I noticed that pam was buggy, I downgraded to 0.72-35, but on the boxes
where cron had been started after the pam upgrade, the bugs only disappeared
after a cron restart.
It makes sense, in a way, if it's libpam0g itself that's buggy, and not
libpam-modules, because long-running processes like cron obviously only load
the library once, on startup.
I added the security tag because if a new release of pam were to fix some
security hole, the fix wouldn't be 100% effective until all processes that
have a copy of the old libpam in memory are restarted.
Andrew
Ps. I assume you know that libpam0g-0.75 breaks cron (it just prints
'Permission denied.', no matter how much debugging you add to pam.d/cron or
how hard you strace/ltrace - though with ltrace you can see the failing pam
call). pam 0.75 also broke VC logins on at least one system.
--
Andrew Korn (Korn Andras) <korn@chardonnay.math.bme.hu>
Finger korn@chardonnay.math.bme.hu for pgp key. QOTD:
Life - brief interlude between nothingness and eternity.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux chardonnay 2.4.18-ak1.2.1-chardonnay #1 Thu Apr 11 15:48:31 CEST 2002 i686
Locale: LANG=C, LC_CTYPE=hu_HU
Versions of packages libpam0g depends on:
ii libc6 2.2.5-6 GNU C Library: Shared libraries an
ii libpam-runtime 0.72-35 Runtime support for the PAM librar
-- no debconf information
--- End Message ---